Bootloader: jumping to either App A or App B

[ELitv.2]

Hello

​

I​ am considering the following approach of the Bootloader.

​

We will divide the internal flash into :

1. Bootloader

2. App A

3. App B

For App A or B we will have a version number. Bootloader will read the version numbers of both and depending upon which application is newer will jump to there. The application doesn't know in advance where it will reside- either in the App A or App B section, which means we're talking about Position Independent Code.

My compiler is Keil.

My 1st question is​ how can I build such a bin image that can reside in either of these 2 sections?

​

Another approach looks clear for me. It is to assign the bottom section to the application and the upper se​ction to the buffer to hold the new version. When the new version is downloaded, we then copy it to the bottom and erase the buffer in the upper.

​

The advantage in the 2nd method is simplicity- no need in PIC. The advantage in the 1st method is speed - no need to copy image from the upper to the bottom section.

My second question is which approach is bett​er in your view and why?

​

​

[Bubbles]

Hello @Community member​ ,

you did not mention what product are you aiming for but this is very common problem. We are addressing it by the dual bank flash. For example AN4767 is dealing with similar case, including even managing code in SRAM, code examples are provided.

Position independent code is quite restricting in many ways, solution similar to the second approach was chosen for example for the X-CUBE-SBSFU code.

BR,

J

[ELitv.2]

Hello @JHOUD​

Thank you very much for your prompt response!

My MCU is one of 2 STM32G0 (need to support 2 p/n).

Unfortunately i don't have Dual Bank.

I understand its advantage, but can't understand how would it help in PIC implementation. Maybe because in both banks the reset address is 0?​

[Bubbles]

Hi @Community member​ ,

yes, the banks can be swapped, so either can be mapped to the address 0 (or 0x0800 0000 even). There is also a dual bank STM32G0Bx if that helps. On the G071 the X-CUBE-SBSFU example uses an arrangement of active slot and download slot. One sector is used to ease the swapping. It's slower, but reliable and not too complicated.

BR,

J

[hs2]

What if always building and deploying 2 binaries linked to section A and B and select the right one to flash with a slightly extended install protocol ?

[ELitv.2]

Yes, I thought about this option.

Why not - not my decisions, a 3rd party is involved and some other not technical stuff. I like a simple solution, which is running only from section A, B is assigned to be a ​buffer only. A new image is put in B and the Bootloader copy B to A.

[Piranha]

Read my last comment in this topic:

https://community.st.com/s/question/0D53W00001Z87EvSAJ/questions-about-an-ab-memory-schema-on-an-stm32-microcontroller

[ELitv.2]

Hi

The mentioned thread looks exactly what I am thinking about. Thank you very much for your help!​

[Pavel A.]

By the way... why position-independent code for Cortex-M is such a big problem?

Linux shared libs are position independent (I guess), and they don't seem to have issues with them?

[ELitv.2]

Indeed, the PIC is widely common in Linux.

In MCU ​I have encountered it rarely. I think I did develop something like that once, it was about 15-20 years ago. I asked about that because I probably need that and because I didn't use use it frequently , I forgot how to do that.

​

As for why it is not that ​common, I think

because it requires furter calculation (the function address) for each function call. That implies a slightly slower running and slightly higher power consumption.

So if it is not needed it is better not to use it.

Once I know how to do that, it's not a problem.​

[hs2]

I think since dynamic linking is required to fix up symbol addresses before running PIC code it can be tricky with a certain runtime impact when running from read-only memory like flash. It should be a bit less challenging when running an application completely from RAM because the runtime linkage is a bit more straight forward and causes no further runtime impact after loading and linking.