Startup & data initialisation problems with gcc4.9.3 under eclipse environnement

[thln]

Hi,

I'm working on nRF52822 device with gcc4.9.3 compiler under eclipse environnement (with gnuarm toolchain plugin).

I have some problems with data initialisation. To check what is wrong I made this simple example:

volatile uint32_t test_data=0x12345678;
volatile uint32_t test_bss = 0;

int main(void) {
	printf("test data %08X\n", (int)test_data);
	test_data = 0;

	printf("test bss %d\n", (int)test_bss);
	test_bss = 1;
}

On the first launch, the console shows:

test data 12345678
test bss 980  

Then I generate a reset to restart my test, the console shows:

test data 00000000
test bss 1

So

a) the "test_data" value is well initialized on the first time, but not on the following ones.

b) the "test_bss" value is never initialized.

Note, my linker options are -T "D:\Eclipse\eclipse64-mars\workbench.arm\nRF52\nRF52_AA.ld" -Xlinker --gc-sections -Wl,-Map,"nRF52.map" --specs=rdimon.specs

I use rdimon library to have the SWO console.

If I try to debug the code, in the statup routine form "gcc_startup_nrf52.s" file, some values (addresses) are not correct.

Reset_Handler:
    ldr r1, =__etext					; <= value correspond to the end of text section
    ldr r2, =__data_start__				; <= value correspond to the start of the RAM (0x20000000)
    ldr r3, =__bss_start__				; !! value = 0x8000 doesn't correspond to the start of bss section !!
...

So the initialization of data is not done here. I guess that it's done inside crt0 routine.

Then to initialize the bss section I've compiled with -D__STARTUP_CLEAR_BSS to be sure the the following code will be added.

#ifdef __STARTUP_CLEAR_BSS
    ldr r1, =__bss_start__				; !! value still set to 0x8000
    ldr r2, =__bss_end__				; !! value = 0x8000 doesn't correspond to the end of bss section !!

    movs r0, 0

    subs r2, r1
    ble .L_loop3_done

.L_loop3:
    subs r2, #4
    str r0, [r1, r2]
    bgt .L_loop3
    
.L_loop3_done:
#endif /* __STARTUP_CLEAR_BSS */	

My linker script is like this

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x80000
  RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x10000
}
...
    .bss :
    {
        . = ALIGN(4);
        __bss_start__ = .;
        *(.bss*)				# bss section content should be located between __bss_start__ and __bss_end__
        *(COMMON)
        . = ALIGN(4);
        __bss_end__ = .;
    } > RAM
...

1. I don't know why bss_start and bss_end are not set to right values

2. I don't know why crt routine doesn't initialize correctly the memory

Thanks for reply.

Regards, Thierry

[RK]

what does the output map file say about the bss section? You should find, somewhere towards the end, it shows what's really an expanded version of the input with addresses on it, eg here's the top of one of mine

.bss            0x20002180      0x844
                0x20002180                __bss_start__ = .
 *(.bss .bss.* .gnu.linkonce.b.*)
 .bss._ZL11main_module
                0x20002180       0xc8 _build/Intermediate/relay_module Custom/Nordic Debug/main.o

is it really at 0x8000?

What crt0.s are you linking?

It would seem a huge fluke if the initialized data works only once, makes me wonder if the reset is actually going all the way back to the reset handler properly.