Error when using __attribute__((at(address))) for data definition

[matic]

Posted on May 16, 2016 at 21:37

Hi.

I tried to use __attribute__((at(address))) to define a global variable at certain address and Keil returned error L6971E, which is described here 

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0496c/CJAIGFIC.html

I don't really understand what is wrong, because if I use address at the beginning of RAM (let say 0x20000020) the error occurs, but if I use higher address (let say 0x20002000), the error doesn't occur.Could anyone please explain what is wrong here and is it just OK if I define higher address, which is not causing an error?Secondly, do I have to be aware of data alignment when using __attribute__((at(address)))?I mean, do I have to use only 0x.......0, 0x.......4, 0x.......8, ... addresses for integers, only 0x.......0, 0x.......2, 0x.......4,  0x.......6, 0x.......8, ... addresses for half-word and any kind of address for bytes?Thanks a lot.

[Tesla DeLorean]

Posted on May 16, 2016 at 22:14

Likely because either the linker has given that space to some earlier defined variable, or it otherwise clashes with how space is being allocated. It's not a multi-pass, best fit, type process.

Carve out a location for these fixed items, ideally in a structure, and outside the normal load region. ie create a region at 0x20000000[0x100] that is purely for this stuff.Having a lot of fixed address variables is a poor design strategy.

[matic]

Posted on May 16, 2016 at 22:29

We just need to have few fixed variables (2 actually), for access them from a Delphi program via debug protocol. So, they should be located on a known address.

Do you have an example, how to create separate location for these fixed items? This is probably done in scatter file?Am I true about address choosing and data alignment (see my original post)?Thanks

[Tesla DeLorean]

Posted on May 16, 2016 at 22:53

I would use the natural alignment the compiler uses for those variables, as it would if you listed then within a structure. The Cortex-M3/4 doesn't have too many alignment criticalities, mostly you'd see issues with double word ie 64-bit integers or doubles.