cancel
Showing results for 
Search instead for 
Did you mean: 

Failure recovery stratergy for UART Bootloader- STM32F446RET6

sneha_giby
Associate III

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.

13 REPLIES 13
TDK
Super User

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".

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

 

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

I think this solution is not possible as firmware is written by STM32Programmer while device is in dfu(more precisely uart bootloader) i.e firmware upgrade through system bootloader, so it is not in our control.

If you are already using STM32CubeProgrammer, use the "verify" option to verify it was written correctly.

If you feel a post has answered your question, please click "Accept as Solution".

This will not help, "Verify" will verify the updated firmware from flash byte by byte with respect to ".elf" or ".bin" file.

i was trying custom bootloader with dual image for the below mentioned original issue.

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.

for the solution you suggested, will not help as the verify will be done only after firmware upgrade completed by stm32programmer by reading back the flash memory and comparing byte by byte to the. elf or .bin file. So once power is removed the device is not detected by the stm32programmer.

Saket_Om
ST Employee

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

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?

 

 

> custom bootloader

Does your bootloader just jump blindly to the user region without checking it in any way first? That's the functionality you need to add. Nothing can help if you just jump blindly.

If you feel a post has answered your question, please click "Accept as Solution".

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