2026-01-06 5:10 AM
I am working with an STM32F0 device and I want to implement a firmware update mechanism.
My current plan is to split the internal flash into three regions:
Bootloader: 0x08000000
Application Slot 1 (App1): 0x08004000
Application Slot 2 (App2): 0x08008000
The bootloader always runs first.
Only one application slot is active at a time.
The update flow is planned as follows:
If App1 is currently running and a new firmware update arrives, the new firmware is written to App2.
If App2 is running, the new firmware is written to App1.
After the update, the bootloader selects which slot to boot.
My concern is about the linker script (.ld) configuration:
When I build a new application firmware, I set the flash origin address in the linker script to:
This works correctly when the firmware is programmed into App1.
However, if the same binary is written to App2 at address 0x08008000, the vector table, reset handler, and absolute addresses inside the firmware will still be linked for 0x08004000.
So my questions are:
Is it correct that a firmware built for 0x08004000 cannot directly run from 0x08008000?
What is the recommended way to manage this kind of dual-slot update system on an STM32F0?
Any guidance or best-practice recommendations would be greatly appreciated.
2026-01-06 5:33 AM
Hello,
This could be done with products having flash in dual bank when it's possible to swap banks. I don't think it's possible to do that with one single bank. The problem here is that not only the start address that should be inline with the current application (defined in the linker file) but also the vector table that needs to be inline with the new flash start address.
2026-01-06 6:36 AM
I solved the vector table issue by relocating the vector table to RAM. With this setup, the system works correctly when only one application is present together with the bootloader. However, after adding a second application and trying to jump to Application 2 from the bootloader, the application does not start. Is there a way to swap or switch between two applications from the bootloader on an STM32F0 device?ale getir anlaşılır
2026-01-06 6:44 AM
As I stated previously, (to my knowledge) I don't think there is a way to do that with a product having one Flash bank.
2026-01-06 3:17 PM
The binary images are not position-independent so they must execute at the address for which they are built. So you build all even versions of the app for target address 0x08004000 and all odd versions at 0x08008000. Then the next version naturally goes to the suitable address in the flash. The bootloader can check that the app binary is written in the correct slot before jump.
2026-01-06 3:25 PM
You can also look into position independent code which some people have had success with, but it's not a supported configuration. Lots of topics on it. I don't think you'll have success without a deep understanding of what's going on at startup. You could likely tailor the startup procedure depending on the PC value.
Position Independent Code Hardfaults With Function... - STMicroelectronics Community
Position independent code for STM32F4 - STMicroelectronics Community
Jumping to code is an independent issue. Works the same regardless of this.