9.10.2. Determining system state

To meet the dynamic timing requirements of the memory system,
any attempt to access system state must occur synchronously. Therefore,
you must force the ARM9TDMI core to synchronize back to system speed.
The 33rd bit of scan chain 1, SYSSPEED, controls this.

You can place a legal debug instruction in the instruction
data bus of scan chain 1 with bit 33 (the SYSSPEED bit) LOW. This
instruction is then executed at debug speed. To execute an instruction
at system speed, a NOP (such as MOV R0, R0) must
be scanned in as the next instruction with bit 33 set HIGH.

After the system speed instructions have been scanned into
the instruction data bus and clocked into the pipeline, you must
load the RESTART instruction into the TAP controller. This causes
the ARM9TDMI automatically to resynchronize back to GCLK when the TAP controller enters
RUN-TEST/IDLE state, and execute the instruction at system speed.
Debug state is re-entered after the instruction completes execution,
when the processor switches itself back to the internally generated DCLK. When the instruction has completed, DBGACK is HIGH. At this point INTEST
can be selected in the TAP controller, and debugging can resume.

To determine whether a system speed instruction has completed,
the debugger must look at SYSCOMP (bit 3 of the debug status register).
To access memory, the ARM9TDMI must access memory through the data
data bus interface, as this access can be stalled indefinitely by nWAIT. Therefore, the only way to determine
whether the memory access has completed is to examine the SYSCOMP
bit. When this bit is HIGH the instruction has completed.

The state of the system memory can be passed to the debug
host by using system speed load multiples and debug store multiples.