3.5.63.  Authentication Status Register, ETMAUTHSTATUS, ETMv3.2 and later

The ETMAUTHSTATUS register characteristics are:

Purpose

Reports the level of tracing currently permitted by the authentication signals provided to the ETM.

Usage constraints

There are no usage constraints.

Configurations

This register is only available in ETMv3.2 or later.

Attributes

See the register summary in Table 3.3 and Reset behavior.

Figure 3.56 shows the ETMAUTHSTATUS register bit assignments.

Figure 3.56. ETMAUTHSTATUS register bit assignments

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Table 3.71 shows the ETMAUTHSTATUS register bit assignments.

Table 3.71. ETMAUTHSTATUS register bit assignments

Bits

Version [a]

Description

[31:8]-Reserved, RAZ.
[7:6][b]v3.2

Permission for Secure non-invasive debug.

See Implementation of the Secure non-invasive debug field for more information.

[5:4]v3.2Reads as b00, Secure invasive debug not supported by the ETM.
[3:2]v3.2

Permission for Non-secure non-invasive debug.

This field is only implemented if the processor implemented with the ETM implements the Security Extensions. When this field is implemented the possible values of the field are:

b10

Non-secure non-invasive debug disabled.

b11

Non-secure non-invasive debug enabled.

This field is a logical OR of the NIDEN and DBGEN signals. It takes the value b11 when the OR is TRUE, and b10 when the OR is FALSE.

If the processor does not support the Security Extensions, bits [3:2] are reserved, RAZ.

[1:0]v3.2Reads as b00, Non-secure invasive debug not supported by the ETM.

[a] The first ETM architecture version that defines the field.

[b] It is implementation defined whether an ETM implements the Secure non-invasive debug field. If the field is not implemented then bits [7:6] are Reserved, RAZ.


Implementation of the Secure non-invasive debug field

It is implementation defined whether an ETM implements the Secure non-invasive debug field. If this field is implemented, its behavior depends on whether the processor implemented with the ETM supports the Security Extensions. If the processor does support the Security Extensions, then the behavior depends on which of the following applies:

  • the processor controls what trace is prohibited

  • the ETM controls what trace is prohibited.

Table 3.72 shows this behavior.

Table 3.72. Implementation of the Secure non-invasive debug field

Security Extensions? [a]Secure tracingBehavior of Secure non-invasive debug field, bits [7:6]
NoSee [b]

The processor is assumed to operate in a Secure state. The possible values of the field are:

b10

Secure non-invasive debug disabled,

b11

Secure non-invasive debug enabled.

The value of this field is a logical OR of the NIDEN and DBGEN signals. It takes the value b11 when the OR is TRUE, and b10 when the OR is FALSE.

YesNot controlled by ETMThe field reads as b00, indicating that the ETM does not control when trace is prohibited.
YesControlled by ETM

The possible values of the field are:

b10

Secure non-invasive debug disabled,

b11

Secure non-invasive debug enabled.

The value of this field is a logical result of:

(SPNIDEN OR SPIDEN) AND (NIDEN OR DBGEN)

It takes the value b11 when the logical result is TRUE, and b10 when it is FALSE. Figure 3.57 shows the logic used to obtain the value of this field.

[a] Does the processor include the Security Extensions?

[b] Not applicable when the processor does not support the Security Extensions.


Figure 3.57. Secure non-invasive debug enable logic when controlled by the ETM

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Copyright © 1999-2002, 2004-2009, 2011 ARM Limited. All rights reserved.ARM IHI 0014Q
Non-ConfidentialID101211