Unable to convert R52 sample project from Arm Compiler for Embedded to GCC

Hi Enzo

I suspect you have not launched the FVP model with "-C cluster0.cpu0.semihosting-stack_base=0".

When the FVP model is launched, some default values for stack/heap base/limit are applied.
You can see the defaults by launching the FVP model on the command-line with e.g.:

C:\Program Files\Arm\Development Studio 2022.1\bin>FVP_BaseR_Cortex-R52x1.exe --list-params | find "semihosting-"
:
cluster0.cpu0.semihosting-heap_base=0                 # (int   , init-time) default = '0x0'    : Virtual address of heap base.
cluster0.cpu0.semihosting-heap_limit=4278190080       # (int   , init-time) default = '0xff000000' : Virtual address of top of heap.
cluster0.cpu0.semihosting-stack_base=4294901760       # (int   , init-time) default = '0xffff0000' : Virtual address of base of descending stack.
cluster0.cpu0.semihosting-stack_limit=4278190080      # (int   , init-time) default = '0xff000000' : Virtual address of stack limit.
:

That explains why you are seeing '0xffff0000' being obtained by the semihosting call at the beginning of _start:
MOVS     r0,#0x16
ADR      r1,{pc}+0xc2 ; 0x1F4
SVC      #0xab

The use of "0" for stack_base and heap_base have particular purposes.  For stack_base=0, it doesn't mean put the stack at 0x0.  At run-time, if the C library startup code gets a stack_base of 0 from that semihosting call, it replaces the 0 with a stack_base address derived from the gcc.ld script by the linker at link-time.

You can see this effect if you step through the code in _start.

Stephen

Hi Enzo

I suspect you have not launched the FVP model with "-C cluster0.cpu0.semihosting-stack_base=0".

When the FVP model is launched, some default values for stack/heap base/limit are applied.
You can see the defaults by launching the FVP model on the command-line with e.g.:

C:\Program Files\Arm\Development Studio 2022.1\bin>FVP_BaseR_Cortex-R52x1.exe --list-params | find "semihosting-"
:
cluster0.cpu0.semihosting-heap_base=0                 # (int   , init-time) default = '0x0'    : Virtual address of heap base.
cluster0.cpu0.semihosting-heap_limit=4278190080       # (int   , init-time) default = '0xff000000' : Virtual address of top of heap.
cluster0.cpu0.semihosting-stack_base=4294901760       # (int   , init-time) default = '0xffff0000' : Virtual address of base of descending stack.
cluster0.cpu0.semihosting-stack_limit=4278190080      # (int   , init-time) default = '0xff000000' : Virtual address of stack limit.
:

That explains why you are seeing '0xffff0000' being obtained by the semihosting call at the beginning of _start:
MOVS     r0,#0x16
ADR      r1,{pc}+0xc2 ; 0x1F4
SVC      #0xab

The use of "0" for stack_base and heap_base have particular purposes.  For stack_base=0, it doesn't mean put the stack at 0x0.  At run-time, if the C library startup code gets a stack_base of 0 from that semihosting call, it replaces the 0 with a stack_base address derived from the gcc.ld script by the linker at link-time.

You can see this effect if you step through the code in _start.

Stephen

Hi Stephen

Thanks to your answer I understood the meaning of the "0" value for stack_base and I added the parameter you suggested. Now my memory allocation is correct.

Therefore, when I step through my code especially while looking at the Disassembly window I am correctly accessing to my main function but program stopped when I reach the first call of printf (enable_mpu() works fine).

I am wondering what could blocked there.

Thanks

Enzo

Hi again Enzo

You don't say what happened when your program stopped, for example, was it hung in a loop, or had an unhandled exception occurred?  My guess is that there is a problem with the heap (which printf uses).  Maybe the stack has grown down too far and collided/corrupted the heap?  As an experiment, did you try making your stack larger earlier?  You'll need to debug your code to find out what caused the problem.  

As a starting point, I suggest you enable capture of the history of instruction execution ("trace"), and enable the trapping of exceptions:

1) Disconnect the Debugger from the FVP
2) Run > Debug Configurations..., select your debug launch config
3) Click on the "DTSL Options..." Edit button
4) In the Trace Buffer tab, select Model Trace.  In the Core Trace tab, select the processor you want to trace, then OK
5) In Debug Configurations, click Debug to re-start a debug session.  Don't run your code yet!
6) Open the Trace view with Window > Show view > Trace
7) Set breakpoints on all the EL1_xxx_Handlers.  These are just dummy "branch-to-self" handlers that do nothing.

Click Debug to start a debug session.  You'll then be able to see in the Trace view where and why your program is stopping, for example, if an invalid address is being accessed.

Hope this helps you to debug your code

Stephen

Hi Stephen thanks for your answer,

Thanks to the Trace windows that you helped me to set up, I can see what is going wrong.

So, when I reach the printf function in my main.c and see associated instruction execution I can see that the exception occurs in the puts function and it seems to be a HANDLE_DATA_ABORT (16) Exception (by the way I do not know what 16 mean there). 

As you suggested I made my stack bigger :

Unless I'm wrong, It seems that the stack is not the issue as the SP value is included in my stack range when the Exception occurs :

And thanks to your tips on breakpoints I noticed that it's redirect to EL1_Abort_Addr which is consistent with the Exception : HANDLE_DATA_ABORT.

I thought it was a heap issue as printf uses heap but I tried to delete the starting address parameter (0x12000) and also to extend heap size independently but the exception occurs as well.

Maybe I am missing something as I am a beginner on Arm DS.

Thanks again for your help Stephen, it really helps me to go through my project configuration.

Enzo

Hi again Enzo

A data abort will occur if an attempt is made to read/write a memory location, but there is no memory at that address, or the MPU has blocked access to that address.

The trace view shows the data abort is caused by the "LDR r0,[r3,#0]" instruction at 0xCF6, which is trying to load a 32-bit word from the address held in r3.  Set a breakpoint on that instruction and run to it.  Check the value of r3 in the Registers view.  Is it a sensible address?  If so, perhaps the MPU is not being programmed correctly, and access to that memory is accidentally being blocked.  Try temporarily disabling the MPU (either comment out the call to enable_mpu(), or use the Registers view to clear the M bit in the System Control register before executing the LDR).

I suspect the problem might be related to the placement of __data_end in your gcc.ld.  In startup.S, the MPU config for "Region 1 - Data" should cover both the RW (.data) _and_ ZI (.bss) regions.  I suggest you check that the memory regions programmed in the MPU config code and the corresponding base/limit symbols in your gcc.ld are as expected.

Hope this helps

Stephen

Hi Stephen,

As you suggested I moved my __data_end to the last line of .bss in the linker script gcc.ld.

I had another DATA_ABORT issue because the address was already used.

As we can see in the map file :

So I shifted all my symbols after that line by 0x04 :

My map file finally looks like this :

And this works,both printf function and my configuration are working well. I am just wondering if there is a cleaner way to do the shifting ?

Thanks for everything Stephen, I am so glad my configuration with GCC is finally working. I hope it will be useful for other users.

Enzo

Hi Enzo

Glad to hear that your project is now working :)

Stephen