STM32 compiled code addresses at 0x0 not 0x08000000

[raimond]

Posted on July 15, 2014 at 14:57

Hi all,

I saw that the current practice is to compile all code at 0x08000000 offset. This is fine for me, but now I have an application with a lot of constant tables in flash, and more important, a ''host'' application which will read those tables from the compiled binary for some post processing.While this is all doable, it is a bit annoying to substract the 0x08000000 offset all the time from the addresses.So, what I have done is to compile the code at 0x0. I knew that the flash area is aliased at 0x0 (it must be anyway). The result is that all seems to work just fine, and I'm now having 0 based addresses burned in the flash.My question is however: Do I miss something? Can I do this safely without having problems at a later time?Compiling the code at 0x0 is quite nice because it is ''compatible'' with other vendors microcontrollers 🙂 #stm32-linker-scripts

[Tesla DeLorean]

Posted on July 15, 2014 at 15:21

Should be fine.

Although why you actually need to subtract 0x08000000 from addresses, which are valid, still confuses me.

[raimond]

Posted on July 15, 2014 at 17:18

I have flash addresses burned in the flash because there are compiled linked lists. The problem is not for the mcu itself, the problem is for a host pc application that should traverse these linked lists read from the compiled binary. 

So, for a STM32 the host will see 0x0800xxxx addresses, and for a LPC1768 for example will see 0x0000xxxx addresses. When the host need to follow an 0x0800xxxx address in the STM32 binary, it should mask the 0x08 because it walks in a binary that is zero based. You know, the binary is not 0x0800xxxx in size 🙂

[Tesla DeLorean]

Posted on July 15, 2014 at 17:43

So you are using an OFFSET, not an ADDRESS, if it processed the data as if it were using pointers you wouldn't need to have the application de-reference the data