cancel
Showing results for 
Search instead for 
Did you mean: 

Position-Independent Code - .data initialization

DWann
Associate III

I'm developing a bootloader for an STM32L0 MCU that will jump to one of two or more application partitions in flash. I'm using IAR 8.22.2.

To make the application binaries position-independent, I've compiled them with the -ropi option. I've also modified the startup code (.s file) to use a Reset_Handler that doesn't have absolute function references in it. At the start of the application, I copy the vector table to SRAM, adjusting all the flash addresses for the current partition offset. I set the VTOR to point to the SRAM location, set the stack pointer, and I'm good to go.

At least, I thought so. I tried jumping to the second partition and running the code, but after some initial excitement at seeing things working, I realized that somehow execution had wandered back into partition 1. To investigate, I compiled 2 separate binaries with the .icf file configured for two different flash partitions. I did a diff on them, expecting to only see differences in the vector table at the beginning of the file. However, I also see differences at the end of the file, in the initializer bytes.

As I read the IAR documentation, -ropi should take care of data initializers as well. ("ROPI = Read-Only Position Independence. This concerns everything that is readonly in the ELF output from the linker. Note that this includes const data and data initializers, i.e. typically everything that is put in FLASH.") Is this not the case? Do I need to use the -rwpi option as well?

I've tried using the -rwpi option, but then I'm completely lost as to how to handle the resulting binary and there are few examples out there (I've found 1 from IAR, but it's very hard to follow.)

Any idea what's going on here? Do I need to use the -rwpi option? If so, are there any good ST-specific examples out there?

Thanks!

10 REPLIES 10
omer Korech
Associate II

Oops, that was the previous version of the bootloader (it was based on ST built in bootloader that resides in system memory ROM).

I am not allowed to share the code of our independent boot loader to which I was referring