Skip to main content
Associate II
April 8, 2026
Question

Failure recovery stratergy for UART Bootloader- STM32F446RET6

  • April 8, 2026
  • 4 replies
  • 344 views

Hi

I have a project with STM32F446RET6 which has custom bootloader and application in user defined location. This project does UART Bootloader for firmware upgrade - issue faced is if the device loses power while in between the firmware upgrade then the device is neither in UART bootloader/DFU mode nor has a valid firmware.

The solution which i want to implement is keeping two image of the application in two slot A and B. Normal working in Slot A  and backup in Slot B. Firmware upgrade happens in Slot A and if fails copy the firmware from Slot B otherwise copy Slot A to Slot B.

can anyone provide a simple logic which can be implemented to check if the firmware upgrade is completed and successful in SlotA.

I would not like to add CRC check.

4 replies

TDK
Super User
April 8, 2026

Use a checksum.

Or write a value at the end of the flash region to signify "firmware was written successfully" Check that before booting to it.

"If you feel a post has answered your question, please click ""Accept as Solution""."
Associate II
April 8, 2026

can you provide how this checksum will work (how to calculate)

I will require more details regarding

a) how to calculate the checksum

b) where to calculate the checksum in bootloader or application

 

Technical Moderator
April 9, 2026

Hello @sneha_giby 

A simple and effective solution is to use an **image size check**. Store the expected firmware size in the image header, count how many bytes are actually written during the UART update, and only mark the image as valid if both values match. 

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
Pavel A.
Super User
April 9, 2026

Original Issue: - Single Image without custom Bootloader, while dfu firmware upgrade through STM32Programmer power removed then device is not able to recover. Since the firmware is erased and no new firmware.

The built-in bootloader cannot be erased, it is always available for recovery. You only have to ensure the BOOT0 pin in the right position. Do you use the BOOT0 pin to start the built-in bootloader?

 

 

Associate II
April 9, 2026

no i am using software jump to bootloader. BOOT0 is always at GND.

MM..1
Chief III
April 9, 2026

You start in ticket CUSTOM bootloader, then custom bootloader is in normal situation first started code. And always check fw A or B before start. Better is use A as factory and update only B. Less flash stress as copy delete A and B...

And primary code and VTOR is compiled for one place , you cant simply load it to A or B...

Associate II
April 15, 2026

So, I am stuck with this issue.

I have only one option to run the application in slot A and keep backup in slot B. Steps followed will be

1) when going for dfu, setting the metadata to upgrade status to updating and upgrade firmware in SLOT A.

2) SLOT A because we have VTOR to the SLOT A address in compile time, after upgrade when reset the device starts from bootloader and check the upgrade status if updating change to testing and jump to Application SLOT_A.

3)In Application in SLOT_A, after delay of 2sec the update status will change to COMFIRM but in between it crashes or reset bootloader check 5 times for failure with the status testing it will copy the SLOT_B to SLOT_A (previous version is copied).

4)when application in SLOT_A changes the status to CONFIRM, application will be copied from SLOT_A to SLOT_B.

@TDK @Saket_Om @MM..1 @Pavel A. do you people think this will be good to implement. Please provide suggestions.