Reputation: 77
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
./waf
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 */
PORT_REGS->GROUP[2].PORT_DIR |= PORT_PC21;
/* Turn on the led */
PORT_REGS->GROUP[2].PORT_OUTCLR |= PORT_PC21;
exit( 0 );
}
/*
* init.c
*/
#define CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
#define CONFIGURE_MAXIMUM_TASKS 1
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT
#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
?
Upvotes: 0
Views: 130
Reputation: 77
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
.
Upvotes: 0
Reputation: 5470
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.
Upvotes: 1