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