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
|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|
Debug event generated
|C_HALT. Internal halt request. Writes to DHCSR.C_HALT are not possible when debug is disabled||See note||Pended|
|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.|