STM32H743 Bootloader Fallback Mechanism for Corrupted Bootloader

[Ekeshwari]

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.

[esarearthur]

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.

[Pavel A.]

IMHO your understanding is correct, except of few details. The boot address is not fixed to 0x08000000 (sector 0).

It is defined by the “option bytes”, separately for BOOT0=1 and BOOT0=1.

So you can select a different bootloader by toggling BOOT0, but the STM32 won't do this without external logic.

As for adding a “small Stage-0 bootloader”: what if that will be corrupted? Who will check it? If you decide to have a backup bootloader, the main bootloader can check itself first and jump to the backup if needed.

But this does not solve the problem with corruption of the vector table. If you could add external logic to drive BOOT0 pin, you could start the backup bootloader first (as it has its own vectors), and let it jump to the primary if needed. Erasing and rewriting the corrupted bootloader can be delayed for later.

Understanding the failure modes is important. Should the backup bootloader sit in a separate sector or bank? it depends.

Adding logic to drive the BOOT0 pin likely is too late, but you can consider this for another project.

“Serious” applications can have redundant controllers with failover, including the whole MCU and its clock circuit, memories etc.

As for remote recovery - again, it depends on what you can drive or access remotely.