Bootloader philosophical question

[miketwo]

Thanks to this forum and CCS's example files, I've been able to write a bootloader for the PIC24FJ256GA110. Woohoo!

My bootloader reads a hex file from external flash and writes that into the PICs program memory. I can upload the hex file into external flash, activate a command, and voila -- a new main() is born.

Now I want to make it more robust and failsafe, because after this unit is deployed I will no longer have physical access to it nor have comms with it for more than a couple minutes at a time. It needs to be smart enough to recover from externally-caused failures on its own.

There's a few basic things, like check-summing the uploaded hex file, dry-running the bootload, etc that will help, but what I'm worried about the most is a reset during the bootload itself. Here's some pseudocode to explain:

[bkamen]

I've worked with 2 bootloaders so far...

One for the PIC32 (using C32) where the application would have the new .HEX file uploaded via HTTP.

1: Because the user could upgrade the web pages or the firmware OR BOTH, I required them to use TAR as an upload format. This has checksums that were enforced or the upload would fail.

THEN, if the upload was successful, I wrote an intel hex decoder that would go through every darn line and validate that it had a correct checksum AND there was a valid "end of file" line -- or it would fail.
Once this happened, a flag was written to external EEPROM that would allow the unit to load up the new file on reboot.

The bootloader was never overwritten. The bootloader would always silently run before the system.

So now on reboot, the unit would check that location for the right value saying there was a valid image available.

So it would load it. The last thing it would do would after a successful re-programming is reset that fingerprint location and then reboot again.

If power was pulled while reprogramming, the unit will just try again until it finished successfully or with a failure.

At this point the only real way to brick the unit was to give it a bad image.. but the bootloader always ran, so the backup to HTTP was SD card. The user could plug in an SD card with the new .HEX...

Also, the bootloader never allowed overwriting itself or some other sensitive areas of memory.

2: on PIC18, I've been using an offshoot of the CCS bootloader that always starts first. (it's less complex than the PIC32 loader I wrote)

I made sure to put in little things like if there was no application, it would say so... AND if the user hit '0' while sitting at the "no application" prompt, it could reboot and allow the user to try again. So unless the bootloader was overwritten, there was always some way to get good firmware onto the unit. Between the WDT timer and the ability for users to hit a key to reset, it never gets "stuck" where someone has to go kick the power.


So in both cases, like most embedded devices *I* buy and own, the bootloader can never be bypassed.
Timers allow for a bum load to reset the system. Granted it will do this over and over.. but each time passing through the bootloader.
In the case where an application load bombs and the bootloader starts but see's "no application" -- the user can still hit "reset".

I don't think I'd ever allow an application to bypass the bootloader. Yikes.
The Reset vector should ALWAYS pass through the bootloader.

No?
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[FvM]

I already told my requirements for a "failsafe" bootloader in previous discussions about PIC24 bootloaders. They basically correspondend to what bkamen said.

- any program memory location used for execution of the bootloader must never been overwritten after factory programming, it should be protected by readonly fuses.
- the boot process must go through the bootloader and there should be a means to activate the bootloader manually, in addition to useful automatic branches, e.g. based on a CRC.

Related to the PIC24/dsPIC memory layout, the "failsafe" requirement implies, that the flash block containing reset and interrupt vectors is protected and can't be overwritten by the bootloader. As previously mentioned, Microchip's AN1157 suggests a respective bootloader layout.

The PIC24 bootloader example provided by CCS in contrast isn't failsafe, because it overwrites sector 0. That's the price for a convenient handling of application interrupt vectors. If you decide for it, you should of course try to minimize the risk of bootloader operation failures, e.g. due to unexpected power loss, but you can't exclude it, strictly spoken,