Bootloader - Dual Slot

[JR2963]

Hi,

I’m working on a bootloader-based setup on STM32 where the application firmware can reside in two different flash regions:

• Slot 1: 0x08008400

• Slot 2: 0x08063400 (e.g., for OTA update)

The goal is to use the exact same binary in both locations — just copy it from one slot to the other and jump to it from the bootloader.

My questions are:

•  Is it possible to run the same application binary from two different flash addresses?

•  If yes, what needs to be done to make it work correctly (e.g., vector table, absolute addressing, stack setup)?

•  Are there known limitations or compiler/linker-related issues that would prevent this from working safely?

---

What I already do in the bootloader:

• I jump to the application slot by reading its MSP and Reset_Handler address from the vector table (first two words).

• I set SCB->VTOR to the address of the application slot before the jump.

• I call __set_MSP() with the application’s stack pointer.

• I deinit peripherals and disable interrupts properly before jumping.

---

What I observe in logs: 

Booth slots are loaded with the same binary files.

When jumping to slot 2 (0x08063400), the output looks like this:

------ Bootloader--------
Jumping to app area 2 on address: 0x08063400
------Application---------
This app is running from Flash region 1
MSP is: 0x2002FB70
VTOR Table is: 0x08063400

So even though the jump target is clearly 0x08063400, and SCB->VTOR is set correctly, the application reports that it is running from Flash region 1 (App1), which suggests that it’s still executing code from the original build address (0x08008400).

Any insight into how this can be made to work — or whether it's a supported pattern — would be much appreciated.

Thanks!

[Pavel A.]

> Is it possible to run the same application binary from two different flash addresses?

This is possible in theory if you manage to build a position independent binary. This has been discussed here several times. IIRC the conclusion was that it is too complicated with the available GCC toolchain and is not worth the effort.

But you may have better luck with the IAR toolchain. Of course you have to fix up the vector table.

The ST example of switching the banks is made in a "clever" way so the per bank binaries have exactly same size and offsets of all vital functions. In real life the binaries would differ significantly.

[JR2963]

Thanks,

Yes I read about it on this community, but have not found any succes solution with FPIC. IAR doesn't come to mind.

From your comment I do not understand if there is solution with "banks" method - for my case.