Please note: We are aware of an issue affecting replies on the Arm Community forums, which may not be loading as expected.

We apologize for any inconvenience and appreciate your patience while we investigate and work to resolve the issue.

Thank you for your understanding.


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

Software breakpoints working intermittently in Arm-DS (with SSE-200 HW)

Hiya,

Using Arm-DS with DStream-ST connected to an FPGA board emulating our SoC based on the SSE-200 design (M33). We are seeing that the SW breakpoints work intermittently. In otherwords, a SW breakpoint in an indefinite software loop is sometimes hit and other times not (in the same run).

Some other info:

  • HW breakpoints work reliably.
  • All code is always ran in secure mode and in secure regions of memory.
  • The code regions we are trying to put breakpoints are RAM (so writable), i.e. starting from addr 0x3000_0000.
  • It appears there are no exception levels on the M33 so I assume thats not the issue.
  • SW breakpoints are intermittent so there is sign of life but not reliable
  • Stepping into code works. Stepping over does NOT.
  • Semihosting is disabled.

Command window log:

start
Reloading program
Starting target with image .../hello_world/hello_world.elf
Running from entry point
wait
Execution stopped in Secure Privileged Thread mode at 0x30000CB4
In startup_rtl.c
0x30000CB4 258,1 {
break -p ".../hello_world/hello_world.c":34
Breakpoint 2 at 0x300008FE
on file hello_world.c, line 34
wait
continue
interrupt
Execution stopped in Secure Privileged Thread mode at 0x300008EA
In hello_world.c
0x300008EA 27,1 }
wait
continue
Execution stopped in Secure Privileged Thread mode at breakpoint 2: 0x300008FE
0x300008FE 34,10 check_me(&grip);

Any help is much appreciated.

Many thanks

Sarah

Parents
  • Hi

    My name is Stephen and I work at Arm.

    One possible cause of what you are seeing is the "cache maintenance" operations not working correctly.
    SSE-200 has an L1 instruction cache on the code AHB interface of the Cortex-M33 core.  Do you have the caches enabled?

    A software breakpoint requires a magic value to be written to RAM.  The debugger should automatically set/unset the magic value, and ensure that any dirty data in the cache is written back to memory after any change (cache maintenance).

    As a quick experiment, try turning off the cache.  Do the software breakpoints then work reliably?

    Hope this helps,

    Stephen

Reply
  • Hi

    My name is Stephen and I work at Arm.

    One possible cause of what you are seeing is the "cache maintenance" operations not working correctly.
    SSE-200 has an L1 instruction cache on the code AHB interface of the Cortex-M33 core.  Do you have the caches enabled?

    A software breakpoint requires a magic value to be written to RAM.  The debugger should automatically set/unset the magic value, and ensure that any dirty data in the cache is written back to memory after any change (cache maintenance).

    As a quick experiment, try turning off the cache.  Do the software breakpoints then work reliably?

    Hope this helps,

    Stephen

Children
No data