Bootloader corrupted at low voltage

I have a number of data loggers using the PIC 18LF4620 powered off a 3.6 volt Lithium Thionyl battery. There is no voltage regulator. In normal operation these wake up, note the time and temperature from a DS1629 RTC, record ten seconds of analog waveform data, store all that to ST M25P64 long term flash memory as a 2048 byte record, then go back to sleep for ten minutes.

Usually I get the back loggers before the battery goes flat and I can extract the data by loading a dump program via the MCS+ Bootloader. This last lot did not come back in time and the batteries are all flat, reading less than 0.5 volts. It looks like the bootloader has been corrupted and after removing the batteries and supplying 3.6 volts, I cannot read any data back. Six units in a row show exactly the same problem.

Are there any 'zero component' tricks that I can use to measure battery voltage when the system has no voltage reference to compare against? Is there a simple RC oscillator that varies with battery volts that I can tap into? If I can find a way to measure battery volts I can put a branch in the code to stop logging when the battery falls below 2.5 volts.

I realise that normal code operation is out the window with a flat battery but has anyone got any suggestions or strategies on how to preserve the bootloader in a low voltage scenario?

Brian

Did you have the code protection on or could you read the PIC with your programmer to see what was actually inside them?

Was the data in the external memory also corrupted?


Would it be possible to make a counter in the logger only allowing it to work a preset number of times and then stop logging? Then you just set this counter to a value that is inside the battery lifetime of the product.

Did you have the Brown out reset turned on? You can set that one using the config bits to different voltage levels and by doing that you could catch when the battery power drops below that level. When the chip try to restart after a brown out you can just check the flag for this event and if it did a reset that way you can branch off and stop logging. This level can be set to 2.0 V or 2.7 V not to 2.5 V but maybe 2.0 V can work or you can accept a slightly shorter lifetime using 2.7V .

Read in the datasheet how to detect a BOR to avoid getting a false indication.

/me

Hi Jumper, thanks for the tips. I do not set code protection. I don't yet know if the main external memory is corrupt. I have to desolder the chips and mount them on a new board to do that - Monday's first task.

The fixed number of logs won't cut it. There are a number of environment variables that make the unit stay on longer/shorter depending on animal activity so I can't predict the number of cycles to log.

The BOR is a good idea. I will research that tonight and see how it looks. I had thought of doing something like the POT or RCTIME command on a fixed RC network. I am guessing but I think that might yield a voltage dependent result tat could work if the BOR does not.

Thanks
Brian

Do you have the possibility to program the PIC on the board using the ICSP? If you have that you can read the PIC on the board and also dump a new program to the PIC that allows you to read the raw data from the external memory without desoldering it first.

Why dont you add the data dumping part of your code to the normal application? Then you dont have to re-program the PIC before dumping the data.

If you need any help let me know.

/me

Hi Jumper,
The data loggers are surgically implanted inside fish and small reptiles. They are quite small and I did not include the ISCP pins for size reasons. In hindsight however, I think ICSP might be the best way in future as you can always blast your way in with the ICSP programmer. The Bootloader is more convenient in most cases which is why I chose it..

Dumping data flattens the battery in a trice so I cannot dump unless I have opened up the logger and attached external power. There is little point in having the dump code in the main logger code and indeed it could be dangerous with a code runaway that could corrupt the already logged data.

I will experiment with BOR and also RCTIME and POT commands to see if I can get a voltage dependent result that can reliably indicate the battery is nearing exhaustion and halt logging.

Cheers
BrianT

You just need to make test points on the PCB or an etched edge connector.

Just for troubleshooting strap in some wires on RB6, RB7, VPP and feed it from your external powersupply. Then you connect the lines in some kind of way to your programmer and you are good to go.

How do you usually program your chips?

I have a PicStart programmer in the beginning that had a 40 pin DIP socket with wires from it as a ICSP programmer. Short cables are recommended :-)

Now I use the ICD2 since I needed a USB programmer....

The M25P64 is specified from 2.7V so I guess that is the value you should use if you want to be sure to store the data properly, Not 2.5V.

/me

parts of CONFIG2L

01 = Brown-out Reset enabled and controlled by software (SBOREN is enabled)

and set the voltage level you want to have. i.e 2.7V.

REGISTER 4-1: RCON: RESET CONTROL REGISTER

bit 0 BOR: Brown-out Reset Status bit
1 = A Brown-out Reset has not occurred (set by firmware only)
0 = A Brown-out Reset occurred (must be set in software after a Brown-out Reset
Note 1: If SBOREN is enabled, its Reset state is ‘1’; otherwise, it is ‘0’.

Now you can have your software looking for the BOR reset status bit and figure out if the battery power is too low. This way you can make sure the PIC doesn't die while writing to the flashmemory as it could happen if it was HW controlled (it would reset instantly when the power drops). If a BOR has happened you can finish all your tasks and power off nicely. At this time you might also want to turn off the WDT so when the pic goes to sleep it is for good. Some batteries recover a little bit and doing this way you can be sure that if the PIC has done one BOR it is off forever after.

/me