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.
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:
Command window log:
startReloading programStarting target with image .../hello_world/hello_world.elfRunning from entry pointwaitExecution stopped in Secure Privileged Thread mode at 0x30000CB4In startup_rtl.c0x30000CB4 258,1 {break -p ".../hello_world/hello_world.c":34Breakpoint 2 at 0x300008FE on file hello_world.c, line 34waitcontinueinterruptExecution stopped in Secure Privileged Thread mode at 0x300008EAIn hello_world.c0x300008EA 27,1 }waitcontinueExecution stopped in Secure Privileged Thread mode at breakpoint 2: 0x300008FE0x300008FE 34,10 check_me(&grip);
Any help is much appreciated.
Many thanks
Sarah
HiMy 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