We have a multi-app bootloader. The application starts with bootloader.uvprojx and then switches to one of the two applications namely: fw2000 and fw3000. So we have 3 binaries/executables on our controller at following addresses of the flash program/code memory space: bootloader at 0x0, fw2000 at 0x2000 and fw3000 at 0x3000 . fw2000 and fw3000 are the same code but these two app firmwares here are compiled using absolute ROM addresses to create fw2000.bin and fw3000.bin. This is done in Keil by setting the address in "Options for target"->"Target"->"IROM1:" -> "Start" address to respective start address .
We have this architecture to update firmware. For that creating bin/hex specific to absolute address is not desirable.
Is there a way to compile a fwXXXX which can be relocatable at both the addresses? Such that, fwXXXX is compiled and the .bin ot .hex can be written at any address (in this case 0x2000 or 0x3000).
Hi Pier, I'm not sure which options to check out of the two: "Options for Target" -> C/C++ there are two check boxes "Read-Only Position Independent" and "Read-Write Position Independent". I'm gonna give this a try: compile the code with Read-Only Position Independent checked. Then write this bin file at 0x3000 and then reboot from the bootloader and switch to 0x3000... see if it executes from there...
When I say 'switch to 0x3000', I mean the bootloader does this: 1) force re-map assigned flash page (in this case 0x3000) to CPU address 0x0 . This is a feature of the microcontroller and not common to Cortex M0 arch. 2) Assign a function pointer to the base address of the firmware (in this case 0x3000). 3) Use the CMSIS function __set_MSP() to the base address of the firmware (in this case 0x3000). 4) Call the funtion which was set in step (2).
So your concern of the vector table being called from an absolute address is handled by the micro-controller's feature of force remap.
Thanks
The interrupt vector table relocation feature is quite common.
All it does, is to make a piece of flash be mapped to the address range where the actual hardware expects to find it.
But it doesn't take care of how the processor - when activating an interrupt - will be able to jump from the vector and into the relocated service routine.
The normal way this is done is that the build tools knows the interrupt vector table will be mapped on top of address zero - but also knows about the exact address where the ISR code is. So the linker produces code that correctly jumps to the ISR. But if you load your code to some other address than what the linker prepared the code for, then this jump will fail.
So the vector remapping fixes the jump into the table but not the jump out of the table and into the ISR. That's something your boot loader needs to fix. If the processor architecture uses absolute or relative jumps, affects how the boot loader needs to modify the interrupt vector table content.
"So your concern of the vector table being called from an absolute address is handled by the micro-controller's feature of force remap."
Umh, no.
The Cortex-M3/M4 have SCB->VTOR, the Cortex-M0 requires an alternate shadowing at address zero to achieve a similar effect.
STILL, the vectors IN THE TABLE point to ABSOLUTE addresses. Which, by definition, is NOT address-independent. If the rest of your code/data is address-independent you can fudge/patch the vector table entries as you write them to FLASH or RAM to account for the specific address they are now situated at.
Thanks! I got what what u were telling about the absolute address entries in the vector table. I'll figure out a way to fix that.
I did NOT understand : "If the rest of your code/data is address-independent". How do I know this? Doesn't checking the "Read-Only Position Independent" box ensure that?
Hi Pier, I tried shifted the vector table to the RAM in the firmware. The ISR funtion pointers are copied in the vector table in RAM. The program runs through the init and then stops working. I'm not able to debug this code.
The reason could be that when the fw2000 is running, it is provided with fw3000.bin . The fw2000 copies the .bin file in the internal flash @ 0x3000. After fw2000 is done writing and veryfying the firmware, the MCU restarts and the bootloader will now boot only fw3000. fw3000 runs though init, I get a few led blinks as expected and then I can't tell what's happening. Is there a way to debug the fw3000 using Keil?
Hi Pier, Out of curiosity I compiled 3 bin files: 1)IROM1 0x2000 2)IROM1 0x3000 3)IROM1 0x3000, I checked the ROPI box in C/C++ tab.
The bin files created using 2) and 3) are identical.
I was thinking that: checking ROPI would make the bin position independent and then even if it is loaded at any address in the flash, it should work.
Correct me if I'm wrong.