@njepsen
What I originally meant was that you should always go to the bootloader on a reset - eg on power up. That way, if the main program totally fails, you can still activate the bootloader and get a new program to load. Many people just put a jump to the bootloader within the main program, triggered by some event, eg a serial command, or switch closure. But then if the main fails, that jump can never be executed.
That is not the same as your scenario though. I know of no really secure way to load a new program, and recover from a failed load. The problem is that there is nowhere within the processor to hold a full copy of the new code as it comes in, and verify that it is valid, before installing it in Flash. The best I have ever managed is to put a very good checksum on the program, and verify that it is valid before starting the flash load.
I use a SHA1 512 bit hash key for the checking and validation, which seems pretty foolproof. The procedure is to create ( and in my case also encrypt ) the program hex file and append the hash to that. Then the bootloader reads that file from the SD card, decrypts it, and computes its own hash and checks that it matches the embedded hash. If that matches, we go ahead to upload the file to flash. I also change the filename on card, so that we dont reload it again. But much later I realised that can lead to your problem too. What I do now is to save the program file system date in eeprom, and compare any files on the card with that date. If the card contains a later date, I load that program into flash. That way I can just simply issue a new program, and all devices will update themselves with no other intervention. Never had that fail yet. But I can see that if a user screws something up, like remove the card or power down during an upload, bad things could still happen. In that case, the user incurs the cost of a service.
↧
