Using a custom SDIO/FAT in the application bootloader for a STM32 chip, is it possible to make the jump from the bootloader to the new firmware fail-safe?

I would like to verify the new firmware sanity before jumping to it and ideally do so in a sandboxed or safe environment to treat failures if need be. All examples and documentation I found verify the firmware has correctly been placed in the flash memory and then jump to it without a second thought.


2 Answers 2


What you're probably looking for is a checksum or a hash of the entire application image.

Say you'd be using CRC32 since the chip may already have hardware support for it.

  1. After compiling the firmware, you create the checksum for it and store it in a separate file.
  2. Transfer both these files onto the filesystem.
  3. The bootloader then reads the firmware image, creating the checksum once again.
  4. If the generated and stored checksums match, then you're good to go.

Sorry if I understood the question incorrectly.

  • \$\begingroup\$ Thank you, this is a great idea. But isn't the MCU doing this with its own set of tools when launching the primary firmware ? Surely it verifies/sandboxes to avoid breaking everything when the firmware is bad ? \$\endgroup\$
    – user35082
    Jan 4, 2014 at 14:57
  • \$\begingroup\$ It most likely does not do this. Anyway, a green tick would be appreciated :) \$\endgroup\$
    – Dzarda
    Jan 4, 2014 at 14:59

If you want to go step further and check the image before each boot, you can include a header in your application image. The header contains meta-information about the application (name, version, CRC/hash) and a checksum.

So you use the following boot process:

  1. Check if header is valid?
  2. Check if image CRC matches the CRC stored in the header.
  3. If checks passed, boot application.

I use this on a STM32 for SD card update. Works very well. The header can be built using the srecord tool and a little script around it.

To make the process failsafe, you can use a STM32 part with two separate flash banks, so you write the new firmware in the inactive flash bank, check it and make the switch over.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.