[DONE] Bug in STM32F407xG.ld and possibly others

[positron]

Hi,

there's a bug in STM32F407xG.ld (and possible other linker scipts)
which prevents static variables to be initialized in certain cases:

In STM32F407xG.ld, we have:

Code: Select all

...
    _etext = .;
    _textdata = _etext;
...

Now, _etext can be an odd address e.g. if the last content of flash is a
string constant with odd size. This results in _textdata being odd
(0x0800f2cd in our case).

Now, crt0.c does a copy loop with u32 access which will silently fail
and not copy _textdata from flash into ram because all the mem accesses
are not aligned. The result is that static variables stay uninitialized.

The best fix is to align the _textdata:

Code: Select all

...
    _etext = .;
    . = ALIGN(4);
    _textdata = .;
...

BTW, I was unable to create a bug report on SF because I did not find a
way to "submit bug" or similar. Is a SF registration required to do this?

[Giovanni]

Hi,

Thanks for reporting this, I will fix all .ld files in 2.6.2.

Submitting bugs requires registration now because spammers... if you don't want to register I will submit this myself.

Giovanni

[positron]

Hi,

as a side note, it might be a good idea to split the linker scripts:

You need STM32F207xY.ld (several of them). Each of them should contain:

Code: Select all

__main_stack_size__    =    4096;
__process_stack_size__  = 2048;

MEMORY
{
   flash    : org = 0x08000000,      len = 1M
   ram        : org = 0x20000000,      len = 112k
   ethram   : org = 0x2001C000,      len = 16k
   ccmram   : org = 0x10000000,      len = 64k
}

ENTRY(ResetHandler)

INCLUDE chibios_default.ld
/* INCLUDE chibios_default_ccm.ld */

All the rest you put into chibios_default.ld.

This way, it is easier to maintain and for people who want to use different flash sections or add new devices, they can simply use their own ld for the definitions and include default again.

INCLUDE follows ld search path (-L).

[Giovanni]

Hi,

I am going to fix that problem tomorrow, it is not so immediate because I have to do it in trunk, 2.4.x, 2.6.x, 3.0.x and Nil...

I thought about the INCLUDE solution, however I am not sure about the search path behavior of the INCLUDE statement.

Giovanni

[Giovanni]

Fixed in repository as bug #430.

Giovanni

[lilvinz]

Sorry to bump up this old thread but i think the issue has not been fixed properly.
I am hitting the exact same problem of the .data LMA not being aligned on a 4 byte boundary.
The patch for #430 doesn't fix this for me.

Searching around reveals the following syntax to align section VMA as well as LMA in linker scripts:

Code: Select all

.section_name ALIGN( vma_alignment ) : ALIGN( lma_alignment )
{
  ...section contents
}

So adding the LMA align to the .data section fixes the issue for me.
I assume that . = ALIGN(4) only aligns the VMA and is thus insufficient
but i am really not an expert on linker scripts.

Cheers,

Vinz

PS: Using gcc-arm-none-eabi-4_8-2014q2 with -Os -flto --gc-sections

[Giovanni]

Thanks, I will dig into the ld documentation tomorrow.

Giovanni

[Giovanni]

Could you provide a simple project that fails? I am not certain about the best approach.

Giovanni

[lilvinz]

Use the RT-STM32F407-DISCOVERY demo, change -O2 to -Os and replace main.c like this:

Code: Select all

#include <stdlib.h>

static char test1[100] = "derftzguihjko";
static const char test2[] = "abcdefghijklmnopqrstuv";

int main(void) {
  size_t i;
  for (i = 0; i < sizeof(test1); ++i) {
    test1[i] = test2[i];
  }
}

The loop code is just to prevent to compiler from optimizing things away.
The resulting sections should then look like this and you can see the odd LMA of the .data section:

Code: Select all

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 startup       000001c0  08000000  08000000  00008000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         000005d7  080001c0  080001c0  000081c0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .stacks       00000800  20000000  20000000  00010000  2**0
                  ALLOC
  3 .data         00000064  20000800  08000797  00008800  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          000000ac  20000864  080007fb  00008864  2**2
                  ALLOC

[Giovanni]

Hi,

I implemented exactly your fix, thanks for the example.

Giovanni