Skip to main content
Associate
July 11, 2026
Question

STM32H743 Bootloader Fallback Mechanism for Corrupted Bootloader

  • July 11, 2026
  • 1 reply
  • 11 views

Hi everyone,

I'm working on an STM32H743-based product that already has a custom bootloader and I'm looking for the best industry practice for implementing a bootloader fallback mechanism.

Current architecture

0x08000000  Primary Bootloader
0x08020000 Factory Application
0x08080000 Default Application

The bootloader already performs:

  • Application validity checks (MSP and Reset Handler)
  • CRC verification of the Factory and Default applications
  • UART firmware update
  • Automatic fallback from Default Application to Factory Application

The applications are working as expected.

New requirement

The new requirement is that if the primary bootloader becomes corrupted, the system should be able to boot from a backup bootloader stored elsewhere in flash, without requiring physical access (the device is remotely deployed).

I understand that after reset the Cortex-M7 hardware simply does:

MSP = *(0x08000000)
PC = *(0x08000004)

and immediately jumps to the Reset_Handler.

My understanding is:

  • If the vector table or Reset_Handler is corrupted, no software can execute.
  • If the vector table is still valid but corruption occurs later in the bootloader, then a small first-stage loader could potentially verify the main bootloader (CRC/signature) and jump to a backup bootloader if necessary.

My questions

  1. Is a small immutable Stage-0 bootloader the standard industry solution for this problem?
  2. If the device has already been deployed with a monolithic bootloader at 0x08000000, is there any safe way to retrofit a Stage-0 using a firmware update, or is that fundamentally impossible because Sector 0 itself must be erased and rewritten?
  3. Are there STM32H743-specific features (dual-bank flash, bank swap, option bytes, etc.) that can provide a true redundant bootloader solution?
  4. How do commercial embedded products (industrial, automotive, medical, etc.) typically implement recovery when the primary bootloader image is corrupted but the system must remain remotely recoverable?

Thanks in advance for any insights.

1 reply

Visitor
July 11, 2026

You can look at cyclone boot. I supports stage 0 and 1. It can be implemented as self IAP, Hybrid IAP or standalone BL.

The documentation is not the best, but surely I believe myself and others in this community can help.