Vector Magic 1.15 Product Key Generator
Maggie Szydlowski
Even if my binary file is loaded properly at address 0x8040000 as seen from STM32CubeProgrammer, the bootloader always jump to the application at location 0x8010000 or back to the bootloader at 0x8000000.
I also tried generating a binary file from the .elf files using the Arm GNU Toolchain arm-none-eabi-objcopy. The generated binary file kept its static reference, so It would not work on the second application slot at 0x8040000.
I would like to generate .bin files that sets dynamically the vector table offset so I don't have to create a binary file for every application slot by changing the USER_VECT_TAB_OFFSET and memory sections. How can I do this?
Thank you for your reply.
I have tried your solution. When I upload the bin file to the second application slot, It still redirects me to the first application slot.
I have tried different methods of modifying SCB->VTOR in the SystemInit function and none seem to work.
Let me know if you have other ideas.
A_Major
What DOES HAPPEN? These things don't operate via magic or random, the MCU operates in a very logical and sequenced way. Start from the BEGINNING, and focus less on where it ended up when it "failed". Determine what it is doing at each step, and why, and if it's not what you expect, reflect on that a litte.
When it starts it pulls values from the table, you can inspect them. When you change the table it will pull destination addresses for the assorted interrupts and handlers from this new table, look at what's in the table, and what the MCU is going to do with those.
If you have firmware images located at multiple addresses you're going to have to navigate the MCU to those through some means of control transfer. You're loading new addresses, and jumping / branching to them.
What's not working about the symbol method? The linker should be establishing the addresses based on the linker script, and conveyed in the .MAP file. If you set the vector table to a symbol it will no longer be dependent on editing a second file with a #define, it will simply get in the normal flow of the linker. The address could be unsuitable, the linker could be confused by demands put on it, but it should be apparent through inspection and basic validation.
It is my understanding as well that .isr_vector follows the flash start address and is causing the error. The only way for me to upload properly at the second application slot my code with my bootloader is by setting the FLASH section in my linker script to the second application start address (i.e FLASH (rx) : ORIGIN = 0x8040000, LENGTH = 256K in my example). This is because the isr_vector will then be aligned to this address.
However, I expect the flash section to start from the first application and include both (Like the original post : FLASH (rx) : ORIGIN = 0x8010000, LENGTH = 448K). I modify in the application's SystemInit to the address of my application dynamically, but I think we should also set isr_vector dynamically.
I have not found a way to do this, this vector is fixed at compile time, not at runtime.
A_Major
I got some pointers but haven't reached to a working solution yet.
We need to compile code using -fPIC flag in compile settings (i.e. Position independent code). This will generate code with relative addressing.
There are other settings/modifications involved to make this working (some in linker, some in start up files). I'm attaching link to a site which explains about this concept. Hope this helps.