Load multiple applications to flash and pass execution from one to another

[DBurr]

Hi,

I'm using an STM32F746ZG and writing my own custom bootloader. The bootloader will work by initially running and determining which of 2 applications to launch, both stored at different locations in the MCU's internal flash memory. How do you pass execution on to one of these 2 applications from the bootloader?

Thanks,

Doug Burrell

[TDK · Accepted solution]

Short answer: Do this, except use the location of your program instead of BootAddr.

https://community.st.com/s/article/STM32H7-bootloader-jump-from-application

[DBurr]

Thanks for the fast response! This FAQ that you're referring to applies to the STM32H7, will the same solution also work for the STM32F7?

[Tesla DeLorean]

It illustrates control transfer.

You're using a micro-controller, you can pretty much test whatever memory region you want, and jump/branch into code there. On the CM7 parts this is typically done via the Vector Table. You might want to review texts on the Cortex parts, technical manuals from ARM, and IAP examples from ST

[DBurr]

Thanks, yes I've done similar stuff on other ARM Cortex MCUs before and it was also through the Vector Table. I'll have a look at the IAP examples.

[Tesla DeLorean]

You can integrity check the images before transferring control. ST does some superficial tests on SP/PC, but real devices would need more rigour so you don't brick the system.

You could also copy an image stored in FLASH to RAM. You might want to think about this if you want the Apps to be interchangeable, ie keep old/new versions

The Cortex-M doesn't provide for relative addressing in the vector table, so the build address fixated by the linker is where the code needs to execute from.

If all the rest of the code is "address independent" an address specific vector table could be constructed in RAM by the loader, and you could do a simple base relocation.

If you stage the apps as object files, the loader could relocate on the fly as it commits them to specific addresses within available Flash space.

[DBurr]

The idea, and one I had previously implemented on another project, is to generate a build specific to a set location in memory and then generate a second build for another location. Basically have the contents of the flash split into 3 areas: 1 for the bootloader and 2 application "partitions". The problem is each "partition" requires a unique build since as you mentioned the Cortex-M doesn't provide for relative addressing in the vector table. But you're saying you could construct an address specific vector table by the bootloader. Where can I find out the specific info needed to do this?

[Tesla DeLorean]

>>Where can I find out the specific info needed to do this?

I use logical deduction/reasoning, it opens a lot of destinations, it takes longer to draw a map.

If you build for two addresses you could "diff" the binary to confirm that the code itself is "address independent". Once you've confirmed the tool settings get you there, you can build for address zero (or 0x08000000), and then you add the new base value/offset to the vector entries.

Carve a space out of the linker's RAM model, or ensure an empty "Vectors" array gets placed at the base of RAM at 0x20000000

Move the vector into the RAM table, fixing it up and set the SCB->VTOR there. VTOR needs to be on a 512-byte boundary (might be larger, check the size of vectors used, move to next binary page size)

[Piranha]

That ST's example is as all ST's code - pretty fragile and dumb. Look at my comment for a much more robust and simpler solution here:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps

[DBurr]

Thanks for the feedback. I've finally got HW and have been testing out the solution. I'm using the initial solution provided by @TDK​ and this seems to work, most of the time, but sometimes it doesn't and after the bootloader has run and handed off execution to the other application there's no activity and the processor appears to be dead. The solution @Piranha​ has suggested won't work for this application because it needs to determine which of 2 application partitions it should branch to and this is done by reading data from a flash chip. Anyway, I don't understand what is going on such that sometimes it works and sometimes it doesn't work. Any suggestions?

Thanks,

Doug Burrell