Table 12.57 shows a list of the valid combination of authentication signals along with its associated debug permissions. Authentication signals are used to configure the processor so its activity can only be debugged or traced in a certain subset of processor modes and security states.
|SPIDEN||DBGEN||SPNIDEN||NIDEN||Secure invasive debug permitted||Nonsecure invasive debug permitted||Secure noninvasive debug permitted||Nonsecure noninvasive debug permitted|
 When DBGEN is LOW, the processor behaves as if DSCR[15:14] equals b00 with the exception that halting debug events are ignored when this signal is LOW.
The NIDEN, DBGEN, SPIDEN, and SPNIDEN input signals are either tied off to some fixed value or controlled by some external device.
If software running on the processor has control over an external device that drives the authentication signals, it must make the change using a safe sequence:
Execute an implementation-specific sequence of instructions to change the signal value. For example, this might be a single STR instruction that writes certain value to a control register in a system peripheral.
If step 1 involves any memory operation, issue a Data Synchronization Barrier (DSB).
Poll the DSCR or Authentication Status Register to check whether the processor has already detected the changed value of these signals. This is required because the processor might not see the signal change until several cycles after the DSB completes.
Issue an Instruction Synchronization Barrier (ISB) exception entry or exception return.
The software cannot perform debug or analysis operations that depend on the new value of the authentication signals until this procedure is complete. The same rules apply when the debugger has control of the processor through the ITR while in debug state.
The relevant combinations of the DBGEN, NIDEN, SPIDEN, and SPNIDEN values can be determined by polling DSCR[17:16], DSCR[15:14], or the Authentication Status Register.