Electronic – STM32 Bootloader: How to ensure only uncorrupted firmware boots

armbootloaderstm32stm32f4

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 /RST low, BOOT0 high 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?

Best Answer

booting into an erased flash leads to lockup quickly

This may or may not happen - depending what was written and what was not. Note that depending on how the flash is updated and timing there might be no erased flash page - just some with new and some with old data.

initial PC/SP [...] The critical window is now only the write of these two words

True, but there will still be a chance for failure - not good enough for safety critical applications.

Note that users might be tempted to use a standard STM32 flashing tool instead of your software - it would work just fine with ROM bootloader but defeats your migitations completely.

Write a custom bootloader into Flash

I strongly recommend this approach if the results could be catastrophic in failure conditions.

Related Topic