You copied the Doc URL to your clipboard.

12.9.2. Cache coherency in debug state

The debugger can update memory while in debug state for the following reasons:

  • to replace an instruction with a BKPT, or to restore the original instruction

  • to download code for the processor to execute on leaving debug state.

The debugger can maintain cache coherency in both these situations with the following features:

  • If bit [2] of the DSCCR is set to 0 while the processor is in debug state, it treats any memory access that hits in either L1 data cache or L2 cache as write-through, regardless of the memory region attributes. This guarantees that the L1 instruction cache can see the changes to the code region without the debugger executing a time-consuming and device-specific sequence of cache clean operations.

  • After the code is written to memory, the debugger can execute either a CP15 I-cache Invalidate All or a CP15 I-cache Invalidate Line by MVA operation.


  • The processor can execute CP15 I-cache Invalidate All or CP15 I-cache Invalidate Line by MVA operation only in privileged mode. However, in debug state the processor can execute these instructions even when invasive debug is not permitted in privileged mode. This exception to the CP15 permission rules described in Coprocessor instructions enables the debugger to maintain coherency in a secure user debug scenario.

  • The CP15 Flush Branch Target Buffer instruction is also valid in debug state regardless of the processor mode. Although the processor implements this instruction as a NOP, making it available in debug state ensures software compatibility with other ARMv7 compliant processors.

  • Execution of the CP15 I-cache Invalidate All operation while in nonsecure state flushes the secure and nonsecure lines from the I-cache.

  • If bit [2] of the DSCCR is set to 0 while the processor is in debug state, then memory writes go through all levels of cache up to the point of coherency, that is, to external memory.

Was this page helpful? Yes No