I am running some example program in ARM Development Studio using FVP (fixed virtual platforms) simulator for A53.
All is OK, I can run the app.
However, the problem is the breakpoints: they don't work in C code, the work only in .S files assembly.
What could be the problem?
Model parameters are -C bp.secure_memory=false -C cache_state_modelled=0.
Hi DanijelI suspect that a breakpoint is being set, but is not being applied for the exception level in which your code is running, and so is not being hit.For example, if your C code is running in EL1, then debug symbols must be loaded for EL1, and the breakpoint must be set for EL1, with e.g. "break EL1N:main"I suggest you take a look at the ready-made example named "startup_Cortex-A53x1_AC6" that is supplied in Arm DS, and its accompanying readme.html that guides you through the example, including setting breakpoints in different ELs.Best regardsStephen
Thanks Stephen.
That's exactly what I am doing: using example named "startup_Cortex-A53x1_AC6"!
Bit I modified it, added some C code to it, called from main.c.
And I ended up with no breakpoints being hit in C.
Hi DanijelAs you've probably spotted, the "startup_Cortex-A53x1_AC6" example is a makefile-builder project that is based on the "startup_Armv8-Ax1_AC6" example. If you want to extend the "startup_Cortex-A53x1_AC6" example by adding a new source file e.g. hello.c then, as a starting point, you must add it to the /src folder of the "startup_Armv8-Ax1_AC6" example, otherwise hello.c will not get compiled.Also, check that symbol files are loaded for all exception levels that your code executes, e.g.:add-symbol-file "${workspace_loc:/startup_Cortex-A53x1_AC6/startup_Cortex-A53x1_AC6.axf}" EL1N:0I have tested this with the addition of a new C file hello1.c containing function hello1(), and the addition of a new function hello2() in main.c, with both functions being called from main(), and both breakpoints are hit as expected - see attached screenshot.If this still doesn't work for you, then revert back to the original "startup_Cortex-A53x1_AC6" example, and try setting a breakpoint on nudge_leds() in timer_interrupts.c. I've also tested that this works as expected.Stephen
Hi Stephen,
What I have done is I made a new project in ADStudio, than I added a folder with /src and /asm files from the example you mention, and as a last step I added another folder with a bunch of my C source files. It all compiles, builds and runs nicely.
I put a few breakpoints in startup.S, and they all work. Also I placed a few breakpoints into GIC*.c and they all work.
However, breakpoints in main.c don't work. Main.c is still in the /src dir as GIC files are. So it's not even my own folder.
Also, none of the breakpoints work in my own source.
What could I have done to cause this strange behavior? I modified main.c, added some lines, however, nothing suspicious. It builds and runs nicely!
Some more info.
I can step through the code until "erret" line below:
bl SetSPISecurityAll
// // Set up EL1 entry point and "dummy" exception return information, // then perform exception return to enter EL1 // .global drop_to_el1drop_to_el1: adr x1, el1_entry_aarch64 msr ELR_EL3, x1 mov x1, #(AARCH64_SPSR_EL1h | \ AARCH64_SPSR_F | \ AARCH64_SPSR_I | \ AARCH64_SPSR_A) msr SPSR_EL3, x1 eret
Until eret is executed here it's all EL3 memory, and than EL1N. When I try to dissasembly Show in Source it says "no source available for address: EL1N...".
Is this drop_to_el1 the problem?
Hi Danijel,The different exception levels (ELx) are essentially different (but overlapping) memory spaces.As Stephen mentioned above, the solution is to load the debug symbols (you do not need to reload the image itself) to the necessary EL level, which is done by the below command (or from the Load menu item in the Debug Control pane).Note how EL1N:0 is specified as the 'offset' - this means it will be loaded to EL1N no matter what EL level the core happens to be in when the command is executed:
add-symbol-file "${workspace_loc:/startup_Cortex-A53x1_AC6/startup_Cortex-A53x1_AC6.axf}" EL1N:0
Understood, and resolved, thank you so much Ronan.
Thank you Stephen too.
Hello
I have a very similar problem with ARM DS 2021.2.
I am running the Cortex R52 startup example code (startup_Cortex-R52.axf) on a virtual platform using FVP and ARM Fast Models.
When a breakpoint is put in the C code (main.c or sort.c), the code never stops on them.
When a breakpoint has been put in the file startup.s, there is no problem.
I have read this thread and understood that this problem could be related to the exception level at which the code is executed.
So, according to Ronan's reply, I added the following command into the default debug configuration for R52:
add-symbol-file "${workspace_loc:/startup_Cortex-R52/startup_Cortex-R52.axf}" EL1N:0
But it does not work, unfortunately.
So my question is : what is the exception level in R52 at which the main.c is executed ?Maybe the configuration for A53 and R52 is not the same in this case ?
or is there any other trick to perform in ARM DS ?
Best Regards
Frederic
I would add that at execution time, the commands window shows me the following error :
ERROR(ITR14-COR274): ! "EL1N:0" is not a valid address! The address space "EL1N:" is not available on this target
So i guess this trick is not OK for the R52
The startup_Cortex-R52 example comes with a ready-made debug launcher that already contains the command you require:add-symbol-file "${workspace_loc:/startup_Cortex-R52/startup_Cortex-R52.axf}" N:0Processors that support the AArch64 instruction set, such as Cortex-A53, have Exception Levels 0 to 3 - see developer.arm.com/.../Privilege-and-Exception-levelsThe Cortex-R52, which supports the AArch32 instruction set, also has ELs, but these map to AArch32 modes: EL2 (Hypervisor), EL1 (SVC, SYS, FIQ, IRQ, SVC, ABT, UNDEF) and EL0 (User). In Arm DS Debugger commands, EL2 (Hypervisor) is represented by the address space prefix: "H:", and the other modes by "N:" (c.f. Non-secure).You can use the "H:" and "N:" address space prefixes in front of any address, for example, when loading symbols (e.g. with the add-symbol-file command example above), or when specifying a memory address in the Memory view, or when specifying a breakpoint, e.g.:break N:compare_sortsThe Address Spaces supported by a target can be viewed with:info memoryHope this helpsStephen