0

I am recently debugging on a Cortex-M4 program which has its text section on a cached memory region. After attaching to the device, I am trying to set a software breakpoint. The breakpoint can be hit and the CPU is halted. However, I cannot do any further debugging (either STEP, or set another breakpoint and run), the PC always sticks to the first breakpoint.

The problem may because of the cache. When the software breakpoint is hit, the debugger should have changed the physical memory region back to its original value, however the instruction cache is not updated. So the CPU keeps executing the breakpoint opcode and never move forward.

The ARM document has the following description in This Link

The instruction cache is not accessible to a debugger. Therefore debugger accesses to cacheable, executable regions of memory might not be coherent with the instructions visible to the instruction side of the processor.

However it don't gives a solution.

I am thinking of manually invalidate the instruction cache after breakpoint is hit. Try to use the trace32 cache clean IC command, but it says the command is locked. Not sure it is a license problem or the command is not supported by Cortex-M4.

Anyone has experience to handle this?

Eric Sun
  • 777
  • 6
  • 20
  • The link you have posted is for ARM11 - not for Cortex-M4, which does not have any c15 registers. – Holger Oct 01 '18 at 11:49
  • As far as I remember the Cortex-M4 core architecture does not define any caches. So if you have caches, they are probably proprietary ones added by the chip manufacturer. Which brings me to the question: Which actual chip are you using? What CPU have you selected in the SYStem.state window of TRACE32? – Holger Oct 01 '18 at 11:52

0 Answers0