Memory Access Restrictions
- Access to invalid memory addresses will crash the target. This includes both explicit reads by the user, and implicit reads as part of some debugger function (such as call stack unwinding). If such problems are suspected then the user should close all un-needed windows to minimize the chances of a failure. Note that some debugger algorithms are dependent on target hardware/software state, and if that state is invalid then the debugger has no protection against this.
- Memory access over JTAG is slow and using multiple debugger features which are memory intensive can slow down the overall debugger responsiveness. Examples include opening many windows simultaneously or using large trace buffers.
- Debugger-initiated reset is the case where the debugger issues a command via the debug port to reset the target. The conventional Intel method via JTAG is to toggle the reset pin on the debug port, but other methods include a TAP-based reset, issuing IO writes to the south complex, and also toggling the power-good line on the debug port. The debugger provides options to select the best method for the target.
- Target initiated reset, including both software flows that reset the target, as well as the user simply power-cycling the target. Detection of these conditions are generally dependent on the power and reset sideband signals on the debug port. If a target does not implement these sideband signals then the debugger may not function as expected.
- Multiple Resets are implemented on some targets due to platform initialization requirements, to the debugger this appears as multiple back to back target-initiated resets. In some cases, the debugger may lose sync with the target, in particular around application of breakpoints.