|ARM Technical Support Knowledge Articles|
The DBGEXT inputs can be used to make breakpoints or watchpoint dependant on some external condition. For example, a particular system might have some "interesting" on-chip signal connected to one of the DBGEXT inputs. The end-user, using debug tools, can then program the core's debug logic such that a breakpoint can be taken only DBGEXT is in a particular state (for example, break only if DBGEXT==1).
This works as follows:
Bit  of a Watchpoint Control Value register specifies the value that the watchpoint unit will compare the DBGEXT signal against.
Bit  of a Watchpoint Control Mask register determines whether or not the inputs are considered by the watchpoint unit for bkpt/wpt generation.
For example, if watchpoint control mask register bit  is asserted, then the watchpoint unit is not sensitive to the state of the DBGEXT signal. If the watchpoint control mask register bit  is clear, then the watchpoint unit *is* sensitive to the DBGEXT signal, and will allow bkpt/wpt generation only if the DBGEXT signal matches the state programmed into the watchpoint control value register bit .
Partner feedback suggests that these signals are rarely used for single-core systems and these inputs are usually just tied-off LOW.
These signals may have more of a real application in multi-core systems which contain dedicated cross-triggering hardware (e.g. CoreSight Embedded Cross Trigger). In this case, it is recommended that these inputs are driven from the cross-trigger network, which enables the DBGEXT inputs to be driven from other signals in the cross trigger network (under debugger and/or software control).
For example, in a dual-core system it might be useful to stop processor #1 only if processor #2 has already been halted (where processor #2 DBGACK drives processor #1 DBGEXT via the cross trigger network).
If the DBGEXT inputs are not used then they must be tied-off to a known state.
Did you find this article helpful? Yes No
How can we improve this article?