Running position independent code on STM32

[szbrozek9]

Posted on July 31, 2011 at 06:19

Running position independent code on STM32

[Tesla DeLorean]

Posted on July 31, 2011 at 14:43

Subject: Running position independent code on STM32

(no text) There's no body to your question, perhaps the forum ate it? The STM32 should have no problem running position independent code, most Thumb2 code should be relatively position independent as most fixed addresses are the ones of peripherals. Check your unspecified compiler settings to confirm if there is an option to turn it on/off, direct the code generator, etc. If you want to copy code in FLASH to RAM, watch that you copy *all* the required code, relative jumps to code/library/functions outside the copy will fail. I write such code in assembler, but to each their own.

[szbrozek9]

Posted on August 01, 2011 at 20:18

I tried editing the post, but it seems the edit went to /dev/null. That's rather frustrating.

I'm trying to write a CAN bootloader for the connectivity line STM32 devices. I can't use the built-in bootloader for a litany of reasons. I'd like to have position independent binaries that I can burn anywhere in flash and then jump to the location of the first address of the application. This is to avoid bricking due to a bad flash.

One of my problems is that any code that I generate with the -fPIC compiler option and the -fPIE linker option doesn't want to execute even when loaded at the bottom of flash memory. The debugger complains about a program counter at 0x00000100.

I did some research and ran across a stackoverflow post that seemed relevant, but I don't know how to parse its contents (I'm only now getting in to the nuts and bolts of how code actually gets executed):

http://stackoverflow.com/questions/5024387/trying-to-load-position-independent-code-on-cortex-m3

Where is the global offset table specified?

At a higher level, I also wonder how to best include the bootloader in my main application, but specify that it loads at the base address of flash and that the rest of the program gets placed above that. I assume it's going to be a bit of hacking with the linker script and using __attributes_ in the function declarations, but this is a problem that I will need to tackle later.

Thanks,

Sasha

[Tesla DeLorean]

Posted on August 01, 2011 at 20:50

I'd go for two distinct pieces, and generally avoid ever overwriting the boot loader. Create two linker script profiles.

You need to re-write the boot loader depends on how complicated you make the loader, and how many bugs you have in it. Being able to run from flash, while writing to a different part, is a benefit and a burden. It so stalls the processor it will likely break external communication. If at all possible, copy the loader to RAM, and run it from there. Alternatively just make the boot loader smart enough to permit you to download a more complicated flash loader into RAM, and then transfer control to it. The GOT is more of an ELF/LINUX issue. The ELF object files are certainly capable of carrying relocation information, and you can fixup any hard references, but this probably isn't particularly helpful by the time you've condensed that into a BIN or HEX file with a fixed address. Your biggest issue is likely to be the fixed addresses of the vectors. You can relocate the table address, but the vectors point to hard addresses. You could place the table in RAM, and resolve the addresses as you copy them.