I have a custom board with an STM32F407 on it. As SWD is not available, I have to program the microcontroller through the UART bootloader.
Imagine that the folllowing sequence of events takes place. I pull the
BOOT0 pin high and after reset the microcontroller enters the bootloader. At my request, the bootloader erases the flash of the microcontroller. I assume that now all words in memory are
0xffffffff. Then I send a sequence of write commands to write the flash, starting at the first byte of my fimware image and continuing to the last.
If power fails or communication is lost somewhere in this process, I have a microcontroller that has an invalid program image in flash. When the microcontroller is subsequently powered on again, with
BOOT0 so as to run the application, it runs what is essentially a corrupted firmware. Depending on the program behavior and attached hardware, the results could be catastrophic.
I cannot find any kind of support to inhibit firmware startup when a corrupt image is present in the STM32F407. Workable mechanisms could be a CRC check before the CPU jumps to the firmware or an "inhibit firmware startup" bit in flash that is set (erased) first during erase and cleared (written 0) last in the update process. However, I find no such provisions in the hardware.
- Write a custom bootloader into Flash that has to be programmed one time. The reset vectors are set to always jump to the custom bootloader. That one checks for the presence and verifies the integrity of the firmware. To that end, the firmware has to include size and checksum information at a place known to the custom bootloader. This solution has the obvious downside of requiring me to get hold of this custom bootloader - writing it myself or adapting something that exists - and that the custom bootloader needs to be loaded first during production.
- Assume that an erased flash leads to a lock up of the processor. I am not yet this convinced that booting into an erased flash leads to lockup quickly. Even if the processor locks up when booting firmware, I can still activate the bootloader by pulling
BOOT0high and then releasing
/RST. During update, after erase, the firmware is written starting just after the initial SP/initial PC reset vector pair. As the last step of the update, the initial PC/SP are written to the first two 32 bit words of the flash. The critical window is now only the write of these two words, reducing the chance of failure by orders of magnitude.
What are sensible strategies to deal with stated problem? Are the options presented above viable?