12.10.3. Authentication signals

Table 12.41 shows a list of the valid authentication signals and the associated debug permissions. Authentication signals are used to configure the CPU so its activity can only be debugged or traced in a certain subset of CPU modes.

Table 12.41. Authentication signal restrictions

DBGENm[a]NIDENm

Non-invasive debug permitted in User and Privileged modes

00No
X1Yes
10Yes

[a] When DBGENm is LOW, the processor behaves as if DBGDSCR[15:14] equals b00 with the exception that halting debug events are ignored when this signal is LOW.


Changing the authentication signals

The NIDENm, and DBGENm input signals are either tied off to some fixed value or controlled by some external device.

If software running on the CPU has control over an external device that drives the authentication signals, it must make the change using a safe sequence:

  1. 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.

  2. If step 1 involves any memory operation, issue a Data Synchronization Barrier (DSB) instruction.

  3. Poll the DBGDSCR or DBGAUTHSTATUS to check whether the CPU has already detected the changed value of these signals. This is required because the system might not issue the signal change to the CPU until several cycles after the DSB completes.

  4. Issue an Instruction Synchronization Barrier (ISB) instruction.

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 CPU through the DBGITR while in debug state.

The values of the DBGENm and NIDENm signals can be determined by polling DBGDSCR[17:16], DBGDSCR[15:14], or the DBGAUTHSTATUS.

Copyright © 2010-2011 ARM. All rights reserved.ARM DDI 0460C
Non-ConfidentialID021511