ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition

Debug Events
For example, if the second memory operation of an STM instruction signals a synchronous Watchpoint debug
event, then when the instruction is re-tried following processing of the debug event, the first memory
operation is repeated. This behavior is not normally permitted for accesses to Device or Strongly-ordered
memory.
To avoid this circumstance, debuggers must not set watchpoints on addresses in regions of Device or
Strongly-ordered memory that might be accessed in this way. The address range masking features of
watchpoints can be used to set a watchpoint on an entire region, ensuring the synchronous Watchpoint debug
event is taken on the first operation of such an instruction.
Asynchronous Watchpoint debug events
An asynchronous Watchpoint debug event acts like a precise asynchronous abort. Its behavior is:
The watchpointed instruction must have completed, and other instructions that followed it, in
program order, might have completed. For more information, see Recognizing asynchronous
Watchpoint debug events.
The watchpoint must be taken before any exceptions that occur in program order after the watchpoint
is triggered.
All the registers written by the watchpointed instruction are updated.
Any memory accessed by the watchpointed instruction is updated.
When invasive debug is enabled and Monitor debug-mode is selected, if Watchpoint debug events are
permitted an asynchronous Watchpoint debug event generates a precise asynchronous Data Abort exception.
An asynchronous Watchpoint debug event is not an abort and is not affected by architectural rules about
aborts, including the rules about external aborts and asynchronous aborts. An asynchronous Watchpoint
debug event:
is not affected by the SCR.EA bit
is not ignored when the CPSR.A bit is set to 1.
On an asynchronous Watchpoint debug event, the DBGDSCR.MOE field is set to Asynchronous
Watchpoint occurred.
Recognizing asynchronous Watchpoint debug events
When an instruction that consists of multiple memory operations is accessing Device or Strongly-ordered
memory, and an asynchronous Watchpoint debug event is signaled by a memory operation other than the
first operation of the instruction, the debug event must not cause Debug state entry or a debug exception until
all the operations have completed. This ensures the memory access rules for Device and Strongly-ordered
memory are preserved.
Examples of instructions that cause multiple memory operations are the LDM and LDC instructions.
ARM DDI 0406B Copyright © 1996-1998, 2000, 2004-2008 ARM Limited. All rights reserved. C3-19