[En-Nut-Discussion] ARM9 problem and arm-eabi section alignment

Harald Kipp harald.kipp at egnite.de
Thu Jul 14 19:53:16 CEST 2011


Hi all,

I experienced a strange problem with ARM9 and the arm-none-eabi
toolchain, while building applications for directly loading into and
running in RAM.

It was the usual story: After adding a few bytes of code, the system
crashes early in NutInit(). After adding more or removing some code, it
runs rock-solid. Typically this is caused by uninitialized memory, stack
problems, invalid pointers, that kind of stuff.

However, in this case the problem appears with httpserv and even less
complicated standard samples, which run fine on other targets.

Well, it turned out, that the linker script was the problem. In

  .data : AT (__etext) { blah...blah } > ram

the "AT (__etext)" is not only dispensable, but quite harmful. If
__etext (the first available address following the text segment) is at,
let's say, 0x2000100c, then the first data item will be physically
placed at this RAM address.

The arm-eabi linker will use 8 byte section alignment by default, using
address 0x20001010 to access the first initialized data item. The result
is a misplacement of all initialized data by 4 bytes.

I'm not sure, but I assume that the previous arm-elf compiler used 4
byte section alignment. That may explain, why this problem didn't appear
earlier.

A short look into our linker scripts shows, that at least

at91sam9260_ram.ld, at91sam9g45_ram.ld and at91sam9xe512_ram.ld

have this problem. After removing "AT (__etext)", all applications work
as expected.

Regards,

Harald


P.S.: If you are not familiar with linker scripts and wondering, what's
the sense of the "AT" directive at all, think about applications running
in Flash. In this case the initialized data must be placed in Flash
memory. Where else? The application may later modify the data by
overwriting initial values. That wouldn't work, if Flash is referenced
for writing. During early initialization the data is simply copied from
Flash to RAM and the application will always reference the RAM locations.



More information about the En-Nut-Discussion mailing list