You copied the Doc URL to your clipboard.

Debug authentication

Debug is enabled using one or more of four signals, DBGEN, NIDEN, SPIDEN, and SPNIDEN. They can enable debug all, debug Non-secure, or debug none. There are different configurations of these signals for both ARM®v8‑M processors and development boards.

The debug control signals have the following meanings:

Table 1-2 Debug control signals

Signal Name Description
DBGEN Debug Enable
NIDEN Non-Invasive Debug Enable
SPIDEN Secure Privileged Invasive Debug Enable
SPNIDEN Secure Privileged Non-Invasive Debug Enable

The ARMv8‑M architecture with Security Extension supports the same external debug control signals as the ARMv8‑M architecture with Main Extension with the same rules for enabling invasive, and non-invasive debug being applied. Unlike the ARMv8‑M architecture with Main Extension specification, the baseline specification states that it is IMPLEMENTATION DEFINED whether many of the debug registers are accessible from software running on the processor. Unless otherwise stated, the Security Extensions do not change this behavior.

The following table shows how the various debug event sources are handled when invasive debug is either disabled or not permitted in the current state.

Table 1-3 Debug event behavior

Debug event source Types of behavior based on the invasive debug settings
Disabled Enabled but prohibited by security level Enabled and allowed
BKPT instruction HardFault HardFault

Debug event generated

C_HALT. Internal halt request. Writes to DHCSR.C_HALT are not possible when debug is disabled See note Pended
VC_CORERESET Ignore
All other Vector catch Ignore
FPB breakpoint. The processor cannot ignore an FPB Breakpoint and it will escalate to HardFault.
EDBGRQ. External halt request. When EDBGRQ is ignored by the processor, the event remains pending in the system because the signal remains asserted.
DWT watchpoint
Was this page helpful? Yes No