newlib init_array contains only 0xffffffff with RTEMS


I'm trying to port RTEMS on the SAME54P20A. I managed to make a basic BSP that compile and a basic application. I compile the application using

./waf configure --rtems=$HOME/rtems/5 --rtems-bsp=arm/same54p20a

But when running the application on the target, it seems that it never gets to the application task. I identified the issue by stepping through the assembly code. A call to no existing function is made during __libc_init_array.

Here is the assembly for the function :

00006ae4 <__libc_init_array>:
    6ae4:   b570        push    {r4, r5, r6, lr}
    6ae6:   4e0d        ldr r6, [pc, #52]   ; (6b1c <__libc_init_array+0x38>)
    6ae8:   4d0d        ldr r5, [pc, #52]   ; (6b20 <__libc_init_array+0x3c>)
    6aea:   1b76        subs    r6, r6, r5
    6aec:   10b6        asrs    r6, r6, #2
    6aee:   d006        beq.n   6afe <__libc_init_array+0x1a>
    6af0:   2400        movs    r4, #0
    6af2:   3401        adds    r4, #1
    6af4:   f855 3b04   ldr.w   r3, [r5], #4
    6af8:   4798        blx r3
    6afa:   42a6        cmp r6, r4
    6afc:   d1f9        bne.n   6af2 <__libc_init_array+0xe>
    6afe:   4e09        ldr r6, [pc, #36]   ; (6b24 <__libc_init_array+0x40>)
    6b00:   4d09        ldr r5, [pc, #36]   ; (6b28 <__libc_init_array+0x44>)
    6b02:   1b76        subs    r6, r6, r5
    6b04:   f000 fe46   bl  7794 <_init>
    6b08:   10b6        asrs    r6, r6, #2
    6b0a:   d006        beq.n   6b1a <__libc_init_array+0x36>
    6b0c:   2400        movs    r4, #0
    6b0e:   3401        adds    r4, #1
    6b10:   f855 3b04   ldr.w   r3, [r5], #4
    6b14:   4798        blx r3
    6b16:   42a6        cmp r6, r4
    6b18:   d1f9        bne.n   6b0e <__libc_init_array+0x2a>
    6b1a:   bd70        pop {r4, r5, r6, pc}
    6b1c:   00008914    andeq   r8, r0, r4, lsl r9
    6b20:   00008914    andeq   r8, r0, r4, lsl r9
    6b24:   00008918    andeq   r8, r0, r8, lsl r9
    6b28:   00008914    andeq   r8, r0, r4, lsl r9

When reaching address 0x6b14 the register r3 contains 0xffffffff which eventually trigger a reset of the board.

Here are the registers states :

r0             0x200016c8          536876744                                                            r1             0xa010001           167837697                                                             │
│r2             0x0                 0                                                                    r3             0xffffffff          -1                                                                    │
│r4             0x1                 1                                                                    r5             0x8918              35096                                                                 │
│r6             0x1                 1                                                                    r7             0x0                 0                                                                     │
│r8             0x0                 0                                                                    r9             0x0                 0                                                                     │
│r10            0x0                 0                                                                    r11            0x0                 0                                                                     │
│r12            0x20000400          536871936                                                            sp             0x20005888          0x20005888                                                            │
│lr             0x6b09              27401                                                                pc             0x6b14              0x6b14 <__libc_init_array+48>                                         │
│xPSR           0x1000000           16777216                                                             fpscr          0x0                 0                                                                     │
│msp            0x20004888          0x20004888 <_ISR_Stack_area_begin+4072>                              psp            0x20005888          0x20005888                                                            │
│primask        0x0                 0                                                                    basepri        0x0                 0                                                                     │
│faultmask      0x0                 0                                                                    control        0x2                 2    

I can't figure out the reason of this.

Here is the application code :

 * app.c
#include <rtems.h>
#include <stdlib.h>
#include "bsp/same54p20a.h"
#include "bsp/port.h"

rtems_task Init(
  rtems_task_argument ignored
  /* Set pin PC21 as output to control LED1 */
  /* Turn on the led */
  exit( 0 );
 * init.c





#include <rtems/confdefs.h>

EDIT (After Tom V comment) Register r3 is loaded by the line

    6b10:   f855 3b04   ldr.w   r3, [r5], #4

So it is loaded with the litteral at address 0x8914 which is (from the dump):

00008914 <__frame_dummy_init_array_entry>:
    8914:   000003e9    andeq   r0, r0, r9, ror #7

If i'm not mistaken, shouldn't r3 take the value 0x3e9 ?

asked on Stack Overflow Feb 10, 2021 by Lucas • edited Feb 10, 2021 by Lucas

2 Answers


The value of r3 is loaded from the address in the literal at 0x6b28.

The literal is address 0x00008914. What is at address 0x00008914 in your disassembly is the word 0x000003e9. This means the value of r3 should be 0x000003e9, and it should call the function at 0x000003e8 (the difference of 1 is because this is an interworking address, the 1 in the LSB means that the target uses the thumb instruction set).

If your debbugger shows that the value of r3 that gets called is 0xffffffff, then the value in memory does not match your disassembly dump.

If this memory is flash ROM then something is wrong with your static linking process or your link script. A relocation might not have been applied to the image that you programmed, but then somehow does get applied in your dump.

If this memory is RAM, then maybe something overwrote that value. If you are using a runtime linker (unusual on a microcontroller) then maybe it never applied the relocation in the first place.

answered on Stack Overflow Feb 11, 2021 by Tom V

In addition to Tom V analysis :

The issue was that some unwanted sections were keep while creating the .hex file. The solution is to add the switch --strip-unneeded to the command objcopy.

answered on Stack Overflow Feb 13, 2021 by Lucas

User contributions licensed under CC BY-SA 3.0