Reverse bootloader, code to perform firmware update can reside in the last sectors?

[RhSilicon]

Hi,

Reverse bootloader, code to perform firmware update can reside in the last sectors of the STM32 Flash?

I am interested in using firmware update via USB Host DFU, but the application has a dual clock speed boot, to reduce consumption when not connected to an external power source, and the display is not used.

There is this video that explains how to make Bootloader with USB Host DFU:

• STM32 USB training - 11.3 USB MSC DFU host labs

The video explains how to implement the bootloader in the first sectors.

Complementary information:

• How to jump to system bootloader from application code on STM32 microcontrollers

But I thought of doing it like in Wi-Fi routers, where it is necessary for the application to initialize the firmware update routine. Has anyone done something similar with STM32?

[TDK]

There's no technical limitation preventing you from putting a firmware update in the last block of flash. The problem is that during the update, if power gets reset after erasing but before flashing, you have now bricked your device and will require another method to program it. Whereas with a properly made bootloader that is called first upon boot, there is no such chance.

[RhSilicon]

---

The problem is that during the update, if power gets reset after erasing but before flashing, you have now bricked your device and will require another method to program it. Whereas with a properly made bootloader that is called first upon boot, there is no such chance.

---

Yes, this is a reality of Wi-Fi routers, I have even had some experiences with the lack of energy, so I have been using UPS to keep the device always powered. But in my case, the device already has a battery and the current idea is to allow the update accessible to the user only during development, so if it is necessary to use the programmer (ST-link), this will not be a problem.

I found some interesting situations about the self-update of updater routines.

DFU code should be updatable

But where should the code that updates our Loader live? It cannot be in the application, or else we would violate the previous principle. It cannot be in the Loader itself either. That leaves one option: a third program tasked with updating the loader. We’ll call it the “Updater”.

https://interrupt.memfault.com/blog/device-firmware-update-cookbook

The STM32WB FUS uses the user application memory region to update the FUS code, it does not use 3 applications:

4.2 FUS self-upgrade

Write the FUS image into the user flash memory

https://wiki.st.com/stm32mcu/wiki/Connectivity:STM32WB_FUS

[RhSilicon]

---

The problem is that during the update, if power gets reset after erasing but before flashing, you have now bricked your device and will require another method to program it. Whereas with a properly made bootloader that is called first upon boot, there is no such chance.

---

Yes, this happens a lot with Wi-Fi routers. To avoid this, it is recommended to use UPS to keep the device always powered.

I found something about updating the update routines themselves. What can be interesting and at the same time demand more development time.

DFU code should be updatable

But where should the code that updates our Loader live? It cannot be in the application, or else we would violate the previous principle. It cannot be in the Loader itself either. That leaves one option: a third program tasked with updating the loader. We’ll call it the “Updater”.

https://interrupt.memfault.com/blog/device-firmware-update-cookbook

The STM32WB FUS uses the user application memory region to update the “DFU” code, it does not use 3 applications:

4.2 FUS self-upgrade

Write the FUS image into the user flash memory

https://wiki.st.com/stm32mcu/wiki/Connectivity:STM32WB_FUS

The current idea is to allow the user to update only during the development phase. An interesting alternative that I found is to use another MCU to perform the updates. For example use an ESP8266, which is compact and easy to implement. I found a project that does the programming of the STM32 via the serial port, and being able to use a smartphone to operate the ESP8266:

https://github.com/csnol/1CHIP-Programmers

[Pavel A.]

> where it is necessary for the application to initialize the firmware update routine. 

IMHO anytime when someone mentions "FOTA" in this forum, this is what they mean. Application downloads updates, and jumps to the bootloader to complete the update. What you call "Reverse bootloader".

Some STM32s can specify the boot address via option bytes (H7 for example) so you can place the bootloader in the last sector (or any other).

[MM..1]

Your question miss info how STM.

A. Bootloader is placed on start sector based on two basic princip. 1. sectors is smaller size as last 2. normal bootloader is on hardware start point, many MCUs start only on first sector.

B. except custom boot exist too system boot AN2606 ...