• State Accepted Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 121 subscribers
  • Views 22366 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Breakpoints not working in C code, only in assembly?

Danijel

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. 

Parents
  • 0

    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

Reply
  • 0

    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

Children
  • 0 in reply to FredericH

    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

  • 0 Arm Employee Badge in reply to FredericH

    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:0

    Processors that support the AArch64 instruction set, such as Cortex-A53, have Exception Levels 0 to 3 - see developer.arm.com/.../Privilege-and-Exception-levels
    The 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_sorts

    The Address Spaces supported by a target can be viewed with:
    info memory

    Hope this helps

    Stephen