Maxim Integrated MAXQ7667 - Manual (Page 213)

12-15 _________________________________________________________________________________________________________
MAXQ7667 User’s Guide
12.3.4 Debug Mode
There are two ways to enter debug mode from background mode: 1) issuance of the debug command directly by the host through the
TAP communication port, or 2) the breakpoint matching mechanism.
The host can issue the debug background command to the debug engine. The response time varies dependent on system conditions
when the command is issued. The breakpoint mechanism provides a more controllable response, but requires that the breakpoints be
initially configured in background mode. No matter the method of entry, the debug engine takes control of the CPU in the same man-
ner. Debug mode entry is similar to the state machine flow of an interrupt except that the target execution address is 8010h, which
resides in the utility ROM instead of the address specified by the IV register that is used for interrupts. On debug mode entry, the fol-
lowing actions occur:
1) Block the next instruction fetch from program memory.
2) Push the return address onto the stack.
3) Set the contents of IP to 8010h.
4) Clear the IGE bit to 0 to disable interrupt handler if it is not already clear.
5) Halt CPU operation.
Once in debug mode, further breakpoint matches or host issuance of the debug command are treated as no operations and do not
disturb debug engine operation. Entering debug mode also stops the clocks to all timers, including the watchdog timer. Temporarily
disabling these functions allows debug mode operations without disrupting the relationship between the original user program code
and hardware-timed functions. No interrupt request can be granted because the interrupt handler is also halted as a result of IGE = 0.
12.3.5 Debug Mode Commands
The debug engine sets the data shift-register status bits to 01b (debug-idle) to indicate that it is ready to accept debug commands
from the host. The host can perform the following operations from debug mode:
• Read register map
• Read program stack
• Read/write register
• Read/write data memory
• Single step of CPU (trace)
• Return to background mode
• Unlock password
The only operations directly controlled by the debug engine are single step and return. All other operations are assisted by debug ser-
vice routines contained in the utility ROM. These operations require that multiple bytes be transmitted and/or received by the host; how-
ever, each operation always begins with host transmission of a command byte. The debug engine decodes the command byte to deter-
mine the quantity, sequence, and destination for follow-on bytes received from the host. Even though there is no timing window spec-
ified for receiving the complete command and follow-on data, the debug engine must receive the correct number of bytes for a par-
ticular command before executing that command. If command and follow-on data are transmitted out of byte order or proper sequence,
the only way to resolve this situation is to disable the debug engine by changing the instruction register (IR[2:0]) and reloading the
debug instruction. Once the debug engine has received the proper number of command and follow-on bytes for a given ROM assist-
ed operation, it responds with the following actions:
• Update the command bits (CMD[3:0]) in the ICDC register to reflect the host request.
• Enable the ROM if it has not been enabled.
• Force a jump to ROM address 8010h.
• Set the data shift register status bits to 10b (debug-busy).
The ROM code performs a read of the ICDC register CMD[3:0] bits to determine its course of action. The ROM can process some com-
mands without receiving data from the host beyond the initially supplied follow-on bytes, while others (e.g., unlock password) require addi-
tional data from the host. Some commands need only provide an indication of completion to the host, while others (read register map)
need to supply multiple bytes of output data. To accomplish data flow control between the host and ROM, the status bits should be used
by the host to assess when the ROM is ready for additional data and/or when the ROM is providing valid data output (Figure 12-2).