66. Debug infrastructure

66.1 Introduction

The debug infrastructure allows software designers to debug and trace their embedded software.

The debug features can be controlled via a JTAG/Serial-wire debug access port, using industry standard debugging tools. A trace port allows data to be captured for logging and analysis.

The trace and debug system is designed to support a variety of typical use cases:

• • Low cost trace

Limited trace capability is available over the single-wire debug output. This supports code instrumentation using “printf”, tracing of data and address watchpoints, interrupt detection and program counter sampling. Single-wire trace can be maintained even when the processor is switched off or clock-stopped.

• • Breakpoint debugging

The processor can be debugged using equipment connected to the JTAG/SWD debug port. This allows breakpoint and watchpoint setting, code stepping, memory access and so on.

• • Tracing code execution via the trace port

Trace information is combined into a single trace stream and output to a trace port analyzer in real time. An ID embedded in the trace allows the analyzer to identify the source of each information packet.

• • Continuous trace capturing in a circular buffer

Instead of streaming it off-chip, the combined trace information can be stored on-chip in a circular buffer. The trace storage can be started and stopped by different means such as a debugger command, a software command, an external trigger signal, an internal event, and so on.

• • Draining the buffer to the trace port

The stored trace can be dumped off-chip to the trace port analyzer. The buffer draining can be initiated by the debugger, software, external trigger, internal event and so on.

• • Reading the buffer with the debugger

The debugger can read the contents of the trace buffer via the debug port. This is slower than the trace port, but allows basic trace functionality on the debugger without the cost of a trace port analyzer.

• • Analyzing stored trace in software

The trace buffer can be read by the processor core, or transferred into system memory by DMA. This powerful feature allows built-in test software to monitor code execution in real time, analyze and identify faults, handle exceptions autonomously, and so on.

• • Uploading stored trace

The stored trace can also be uploaded to a host machine using one of the MCU's many communication interfaces (USB, USART, SPI, I2C, Ethernet, CAN and so on). This is especially useful if the trace port is not accessible, for example remote monitoring and failure analysis of a deployed product.

66.2 Debug infrastructure features

A comprehensive set of trace and debug features is provided to support software development and system integration:

• • Breakpoint debugging
• • Code execution tracing
• • Software instrumentation
• • Cross-triggering
• • JTAG debug port
• • Serial-wire debug port
• • Trigger input and output
• • Serial-wire trace port
• • Trace port
• • Arm ^® CoreSight ^™ debug and trace components.

The CoreSight components are described at high level in this document. Detailed information is available in the Arm ^® documents referenced in Section 66.10 .

66.3 Debug infrastructure functional description

66.3.1 Debug infrastructure block diagram

The block diagram shows the logical partitioning of the debug infrastructure.

Figure 1002. Block diagram of debug infrastructure

66.3.2 Debug infrastructure powering, clocking and reset

Power domains

The debug components are all located in the core power domain. This means that a debug session is disconnected if the core is powered down, for example in standby mode. This can be prevented by enabling low power emulation mode via the DBGMCU_CR.DBG_STANDBY register bit.

Clock domains

Figure 1003. Clock domains of debug infrastructure

The debugger supplies the clock for the debug port, swtclk, via the debug interface pin, JTCK/SWCLK. This clock is used to register the serial input data in both serial wire and JTAG mode, as well as to operate the state machines and internal logic of the debug port. It must therefore continue to toggle for several cycles after the end of an access, to ensure that the debug port returns to the idle state.

The SWJ-DP contains an asynchronous interface to the ck_dbg domain, which covers the rest of the SWJ-DP and the access ports.

ck_dbg clocks the trace components in the core power domain: System ROM table 2, CoreSight trace funnel, ETF, system CTI and TPIU. It is a gated version of the core domain system clock (rcc_hclk3).

traceckin is the trace port clock. It is derived from the TRACECLKIN input.

The debug clock, ck_dbg, can be enabled and disabled by a register bit in the DBGMCU or by the debugger using the CDBGPWRUPREQ bit in the debug port CTRLSTAT register. The clock must be enabled before the debugger can access any of the debug features on the device. It should be disabled at power up and when the debugger is disconnected, to avoid wasting energy.

The debug and trace components included in the processor (ETM ITM, DWG, FPB and so on) are clocked with the corresponding core clock (rcc_c_ck).

Debug with low-power modes

The device includes power-saving features allowing individual power domains to be switched off or stopped when not required. If a power domain is switched off or not clocked, all debug components in that domain are inaccessible to the debugger. To avoid this, power saving mode emulation is implemented. If the emulation is enabled for a domain, the domain still enters power saving mode, but its clock and power are maintained. In other words, the domain behaves as if it is in power saving mode, while the debugger does not lose the connection.

The emulation mode is programmed in the MCU Debug (DBGMCU) unit. For more information, refer to Section 66.8

Reset of debug infrastructure

The debug components, except for the debug port and access ports, are reset by a system or power on reset. The debug port (SWJ-DP) is reset by a power-on reset or a low level on nJTRST.

66.3.3 Security

The trace and debug components allow a high degree of access to the processor and system during product development. In order to protect user code and ensure that the debug features can not be used to alter or compromise the normal operation of the finished product, these features can be disabled or limited in scope.

Debugger access is disabled while the processor is booting from system flash memory.

The following authentication signals are used by the system to determine which debug features are enabled or disabled:

• • dbgen : global enable for all debug features
  • 0: All debug features are disabled.
  • 1: Debug features are enabled.
• • niden : enables trace and performance monitoring (non-invasive debug).
  • 0: Trace generation is disabled.
  • 1: Trace generation is enabled.

For detailed information on the behavior of each component according to the state of the authentication signals, refer to the relevant component chapter or to the relevant Arm® technical documentation.

The state of the signals are set according to the debug state as shown in Table 765 .

Table 765. Authentication signal states

The debug state depends on the product life cycle state, and the debug authentication state (see Section 66.3.4: Debug authentication ).

Table 766. Authentication signal states

1. The level of debug access is defined by the SBS debug control register (SBS_DBGCR) .

66.3.4 Debug authentication

Figure 1004. Product life cycle states and debug authentication

graph TD; CLOSED[CLOSED] --> DA[Debug authentication]; subgraph DA [Debug authentication]; DA_D{Debug authentication}; DA_D --> CD[Constrained-debug]; DA_D --> REG[Regression]; end; CD --> OPEN[OPEN]; REG --> OPEN[OPEN]; OPEN --> CLOSED;

Figure 1004 shows the product life cycle and debug authentication states.

If the device is in CLOSED (product life cycle) state, the debug state is CLOSED. The debug authentication procedure allows a trusted debugger to reopen access without compromising sensitive information called the Root Of Trust (ROT).

Re-opening the debug is possible only if sensitive asset security is ensured. This is called Constrained Debug, as constraints ensure the security of the ROT information.

Alternatively, a partial or full regression mechanism can be used when security of sensitive information cannot be guaranteed. This is called regression, as regression ensures removal of the sensitive information before reopening the debug.

• • Full regression corresponds to releasing all code and assets. The intermediate state which allows full regression management is called Regression.

Debug authentication control principle

The debug authentication feature is one of the most critical security features of the system considering that with a debugger one can get access to a large part of the system.

In order to control re-opening of the debug, the device imposes a debug authentication protocol.

The protocol implements a challenge response mechanism based on asymmetric cryptography to authenticate the host. It relies on a key pair, with a Public Key stored in the device, and a Private Key from the host library which is used to sign a random value (the challenge) generated by the device.

The protocol implements a bidirectional communication between the host and the device through a mailbox interface located in the DBGMCU.

The host can write to the mailbox via the JTAG/SWD interface. It expects to get responses and messages from the device via the same mailbox. For details on this protocol, refer to the Application .

The Debug Authentication protocol is launched on a Power On Reset of the device, when an “open request” message is posted by the host.

The protocol is based on:

• • Initial message => Posted by the host combined with a reset to launch the Debug Authentication process on the device.
• • Challenge message => The device generates a random value, to be signed by the host, when sending back the response.
• • Response => The host sends a message to the device proving its authenticity. This is done using a tool to generate a token.

The implementation of the feature on the device is ensured by code embedded in the System Flash. This code is called automatically after reset if an initial message has been posted by the host in the mailbox.

After a first sequence of mutual authentication to align on protocol version, type of device, etc. the device generates a random value that should be signed by the host with a Private Key when building the response.

The STMicroelectronics implementation is based on the ARM PSA-ADAC solution for Debug Authentication.

The Debug Authentication can be implemented using a proprietary or open source protocol.

As this feature is critical for security, the STM32H7 comes with Debug Authentication provisioned in System Flash. STMicroelectronics provides the host tools integrated with some debug environments (IDEs).

66.4 Serial-wire and JTAG debug port (SWJ-DP)

The SWJ-DP is a CoreSight component that implements an external access port for connecting debugging equipment.

The port can be configured as:

• • a 5-pin standard JTAG debug port (JTAG-DP)
• • a 2-pin (clock + data) “serial-wire” debug port (SW-DP)

The two modes are mutually exclusive, since they share the same IO pins.

By default, the JTAG-DP is selected on system or power-on reset. The five IOs are configured by hardware in debug alternative function mode. The SWJ-DP incorporates pull-up resistors on the JTDI, JTMS/SWDIO, and nJTRST lines, as well as a pull-down resistor on the JTCK/SWCLK line.

A debugger can select the SW-DP by transmitting the following serial data sequence on JTMS/SWDIO: ...,(50 or more ones),...,0,1,1,1,1,0,0,1,1,1,1,0,0,1,1,1... (50 or more '1's)...

JTCK/SWCLK must be cycled for each data bit.

In SW-DP mode, the unused JTAG lines JTDI, JTDO and nJTRST can be used for other functions.

All SWJ port IOs can be reconfigured to other functions by software, in which case debugging is no longer possible.

66.4.1 Serial wire debug port

The serial wire debug protocol uses two pins:

• • SWCLK: clock from host to target
• • SWDIO: bi-directional serial data

Serial data is transferred LSB first, synchronously with the clock. A transfer comprises three phases:

1. 1. packet request (8 bits) transmitted by the host
2. 2. acknowledge response (3 bits) transmitted by the target
3. 3. data transfer (33 bits) transmitted by the host (in the case of a write) or target (in the case of a read)

The data transfer only occurs if the acknowledge response is OK.

If the direction of the data is reversed between each phase, a single clock cycle turn-around time is inserted.

Table 767. Packet request

Table 768. ACK response

Table 769. Data transfer

Figure 1005 shows successful write and read transfers.

Figure 1005. SWD successful data transfer

For any FAULT or WAIT ACK response from the target, the data transfer phase is canceled, unless overrun detection is enabled, in which case the data is ignored by the target (in the case of a write), or not driven (in the case of a read).

A line reset must be generated by the host when it is first connected, or following a protocol error. The line reset consists of 50 or more SWCLK cycles with SWDIO high, followed by two SWCLK cycles with SWDIO low.

For more details on the Serial Wire debug protocol, refer to the Arm® Debug Interface Architecture Specification [1].

Note: The SWJ-DP implements SWD protocol version 2.

66.4.2 JTAG debug port

Figure 1006. JTAG TAP state machine

stateDiagram-v2
    [*] --> Test-Logic-Reset: JTMS=1
    Test-Logic-Reset --> Test-Logic-Reset: JTMS=1
    Test-Logic-Reset --> Run-Test/Idle: JTMS=0
    Run-Test/Idle --> Run-Test/Idle: JTMS=0
    Run-Test/Idle --> Select-DR-Scan: JTMS=1
    Run-Test/Idle --> Select-IR-Scan: JTMS=1
    Select-DR-Scan --> Select-DR-Scan: JTMS=1
    Select-DR-Scan --> Capture-DR: JTMS=0
    Select-IR-Scan --> Select-IR-Scan: JTMS=1
    Select-IR-Scan --> Capture-IR: JTMS=0
    Capture-DR --> Capture-DR: JTMS=1
    Capture-DR --> Shift-DR: JTMS=0
    Capture-IR --> Capture-IR: JTMS=1
    Capture-IR --> Shift-IR: JTMS=0
    Shift-DR --> Shift-DR: JTMS=0
    Shift-DR --> Exit1-DR: JTMS=1
    Shift-IR --> Shift-IR: JTMS=0
    Shift-IR --> Exit1-IR: JTMS=1
    Exit1-DR --> Exit1-DR: JTMS=1
    Exit1-DR --> Pause-DR: JTMS=0
    Exit1-IR --> Exit1-IR: JTMS=1
    Exit1-IR --> Pause-IR: JTMS=0
    Pause-DR --> Pause-DR: JTMS=0
    Pause-DR --> Exit2-DR: JTMS=1
    Pause-IR --> Pause-IR: JTMS=0
    Pause-IR --> Exit2-IR: JTMS=1
    Exit2-DR --> Exit2-DR: JTMS=0
    Exit2-DR --> Update-DR: JTMS=1
    Exit2-IR --> Exit2-IR: JTMS=0
    Exit2-IR --> Update-IR: JTMS=1
    Update-DR --> Update-DR: JTMS=0
    Update-DR --> Run-Test/Idle: JTMS=1
    Update-IR --> Update-IR: JTMS=0
    Update-IR --> Run-Test/Idle: JTMS=1
  

The JTAG-DP implements a TAP state machine (TAPSM) based on IEEE 1149.1-1990. The state machine is shown in Figure 1006. It controls two scan chains, one associated with an instruction register (IR) and one with a number of data registers (DR).

When the TAPSM goes through the Capture-IR state, 0b0001 is transferred into the instruction register (IR) scan chain. The IR scan chain is connected between JTDI and JTDO.

While the TAPSM is in the Shift-IR state, the IR scan chain shifts one bit for each rising edge of JTCK. This means that on the first tick:

• • The LSB of the IR scan chain is output on JTDO
• • Bit [n] of the IR scan chain is transferred to bit [n-1]
• • The value on JTDI is transferred to the MSB of the IR scan chain.

When the TAPSM goes through the Update-IR state, the value scanned in the IR scan chain is transferred to the instruction register.

When the TAPSM goes through the Capture-DR state, a value is transferred from one of the data registers onto one of the DR scan chains, connected between JTDI and JTDO.

The value held in the instruction register determines which data register, and associated DR scan chain, is selected.

This data is then shifted while the TAPSM is in the Shift-DR state, in the same way as the IR shift in the Shift-IR state.

When the TAPSM goes through the Update-DR state, the value scanned in the DR scan chain is transferred to the selected data register.

When the TAPSM is in the Run-Test/Idle state, no special actions occur. The IDCODE instruction is loaded in IR.

When active, the nJTRST signal resets the state machine asynchronously to the Test-Logic-Reset state.

The data registers corresponding to the 4-bit IR instructions are listed in Table 770 .

Table 770. JTAG-DP data registers

Table 770. JTAG-DP data registers (continued)

The DR registers are described in more detail in the Arm® Debug Interface Architecture Specification [1].

66.4.3 Debug port registers

The SW-DP and JTAG-DP both access the debug port (DP) registers. These are listed in Table 771 .

The debugger can access the DP registers as follows:

1. 1. Program the SELECT register DPBANKSEL field in the DP to select the register bank to be accessed (see Table 771 )
2. 2. Program the A[3:2] field in the DPACC register, if using JTAG, with the register address within the bank. Program the R/W bit to select a read or a write. In the case of a write, program the DATA field with the write data. If using SWD, the A[3:2] and R/W fields are part of the Packet Request word sent to the SW-DP with the APnDP bit reset (see Table 767 ). The write data is sent in the data phase.

Table 771. Debug port registers

1. 1. Access to the AP ABORT register from the JTAG-DP is done using the ABORT instruction.
2. 2. Only accessible via SW-DP. Register is “reserved” via JTAG-DP.

Debug port identification register (DP_PIDR)

Address offset: 0x0

Reset value: 0x6BA0 2477

Bits 31:28 REVISION[3:0] : Revision code

0x6

Bits 27:20 PARTNO[7:0] : Debug port part number

0xBA

Bits 19:17 Reserved, must be kept at reset value.

Bit 16 MIN : Minimal debug port (MINDP) implementation

0: MINDP not implemented (transaction counter and pushed operations are supported)

Bits 15:12 VERSION[3:0] : DP architecture version

0x2: DPv2

Bits 11:1 DESIGNER[10:0] : JEDEC designer identity code

0x23B: Arm ^®

Bit 0 Reserved, must be kept at reset value.

Debug port abort register (DP_ABORT)

Address offset: 0x0

Reset value: 0x0000 0000

Bits 31:5 Reserved, must be kept at reset value.

Bit 4 ORUNERRCLR : Overrun error clear bit

0: No effect

1: Clear CTRLSTAT register's STICKYORUN bit

Bit 3 WDERRCLR : Write data error clear bit

0: No effect

1: Clear CTRLSTAT register's WDATAERR bit

Bit 2 STKERRCLR : Sticky error clear bit

0: No effect

1: Clear CTRLSTAT register's STICKYERR bit

Bit 1 STKCMPCLR : Sticky compare clear bit

0: No effect

1: Clear CTRLSTAT register's STICKYCMP bit

Bit 0 DAPABORT : Abort current AP transaction

The transaction is aborted if an excessive number of WAIT responses are returned, indicating that the transaction has stalled.

0: No effect

1: Abort transaction

Debug port control/status register (DP_CTRLSTAT)

Address offset: 0x4

Reset value: 0x0000 0000

Bit 31 CSYSPWRUPACK : System domain power-up status bit - not used in this device

Bit 30 CSYSPWRUPREQ : System domain power-up control bit - not used in this device

Bit 29 CDBGPWRUPACK : Debug domain power-up status bit

This bit is read-only. It returns the status of the debug domain power-up acknowledge signal from the power controller.

0: domain powered down

1: domain powered up

Bit 28 CDBGPWRUPREQ : Debug domain power-up/down control bit

This bit controls the debug domain power-up/down request signal to the power controller.

0: power-down requested

1: power-up requested

Bit 27 CDBGRSTACK : Debug domain reset status bit - not used in this device

Bit 26 CDBGRSTREQ : Debug domain reset control bit - not used in this device

Bits 25:24 Reserved, must be kept at reset value.

Bits 23:12 TRNCNT[11:0] : Transaction counter

To program a sequence of transactions to incremental addresses via an AP, TRNCNT bits are loaded with the number of transactions to perform. It is decremented on successful completion of each transaction.

Bits 11:8 MASKLANE[3:0] : Pushed-compare and pushed-verify masking bits

The field indicates the bytes to be masked in pushed-compare and pushed-verify operations (DP_CTRLSTAT register's field TRNMODE = 1 or 2). In the pushed operations, the word supplied in an AP write transaction is compared with the current value at the target AP address.

0b1XXX: include byte lane 3 in comparisons

0bX1XX: include byte lane 2 in comparisons

0bXX1X: include byte lane 1 in comparisons

0bXXX1: include byte lane 0 in comparisons

The bit indicates;

• – a parity or a framing error on the data phase of a write operation, or
• – a write operation that had been accepted by the DP has then been discarded without being submitted to the AP

This bit is read-only. It is reset by writing 1 to the WDERRCLR bit of the DP_ABORT register.

0: No error

1: Error has occurred

This bit is reserved in JTAG-DP.

This bit indicates the response to the last AP read access. It is read-only.

0: Read not OK

1: Read OK

This bit is Reserved in JTAG-DP.

This bit indicates that an error occurred during an AP transaction.

0: No error

1: Error has occurred

In the SW-DP, this bit is reset by writing 1 to the STKERRCLR bit of the DP_ABORT register.

In the JTAG-DP, this bit is reset by programming it to 1.

This bit indicates that a match occurred in a pushed operation.

0: Match if TRNMODE = 0x1; no match if TRNMODE = 0x2

1: No match if TRNMODE = 0x1; match if TRNMODE = 0x2

In the SW-DP, this bit is reset by writing 1 to the STKCMPCLR bit in the DP_ABORT register.

In the JTAG-DP, this bit is reset by programming it to 1.

For read operations, this field must be set to 0x0.

0x0: Normal operation - AP transactions are passed directly to the AP.

0x1: Pushed-verify operation. The DP stores the write data and performs a read transaction at the target AP address. The result of the read operation is compared with the stored data. If they do not match, the STICKYCMP bit is set.

0x2: Pushed-compare operation. The DP stores the write data and performs a read transaction at the target AP address. The result of the read is compared with the stored data. If they match, the STICKYCMP bit is set.

0x3: Reserved

In pushed operations, only the data bytes indicated by the MASKLANE field are included in the comparison.

This bit indicates that an overrun occurred (a new transaction received before previous transaction completed). This bit is only set if the ORUNDETECT bit is set.

0: No overrun

1: Overrun occurred

In the SW-DP, this bit is reset by writing 1 to the ABORT register's ORUNERRCLR bit. In the JTAG-DP, this bit is reset by writing a 1 to it.

0: Overrun detection disabled

1: Overrun detection enabled. In the event of an overrun, the STICKYORUN bit is set and subsequent transactions are blocked until the STICKYORUN bit is cleared.

Debug port data link control register (DP_DLCR)

Address offset: 0x4

Reset value: 0x0000 0040

Bits 31:10 Reserved, must be kept at reset value.

Bits 9:8 TURNROUND[1:0] : Tristate period for SWDIO

0x0: 1 data bit period

0x1: 2 data bit periods

0x2: 3 data bit periods

0x3: 4 data bit periods

Bits 7:0 Reserved, must be kept at reset value.

Debug port target identification register (DP_TARGETID)

Address offset: 0x4

Reset value: 0x1485 0041

Bits 31:28 TREVISION[3:0] : Device revision number

0x1

Bits 27:12 TPARTNO[15:0] : Target part number

0x4850: STM32H7Rx/7Sx

Bits 11:1 TDESIGNER[10:0] : Target designer JEDEC code

0x020: STMicroelectronics

Bit 0 Reserved, must be kept at reset value.

Debug port data link protocol identification register (DP_DLPIDR)

Address offset: 0x4

Reset value: 0x0000 0001

Bits 31:28 TINSTANCE[3:0] : Target instance number
These bits define the instance number for this device in a multi-drop system.
0x0

Bits 27:4 Reserved, must be kept at reset value.

Bits 3:0 PROTSVN[3:0] : Serial Wire Debug protocol version
0x1: Version 2

Debug port resend register (DP_RESEND)

Address offset: 0x8

Reset value: 0x0000 0000

Bits 31:0 RESEND[31:0] : Last AP read or DP RDBUFF read value
These bits contain the value that was returned by the last AP read or DP RDBUFF read.
Used in the event of a corrupted read transfer.

Debug port access port select register (DP_SELECT)

Address offset: 0x8

Reset value: 0xXXXX XXXX

Bits 31:24 APSEL[7:0] : Access port select bits

These bits select the access port for the next transaction.

0x00: AP0 - system debug access

0x01: AP1 - Cortex M7

0x02 to 0x1F: Reserved

Bits 23:8 Reserved, must be kept at reset value.

Bits 7:4 APBANKSEL[3:0] : AP register bank select bits

These bits select the 4-word register bank on the active AP for the next transaction.

Bits 3:0 DPBANKSEL[3:0] : DP register bank select bits

These bits select the register at address 0x4 of the debug port.

0x0: CTRLSTAT register

0x1: DLCR register

0x2: TARGETID register

0x3: DLPIDR register

0x4 to 0xF: Reserved

Debug port read buffer register (DP_RDBUFF)

Address offset: 0xC

Reset value: 0x0000 0000

Bits 31:0 RDBUFF[31:0] : Last AP read value

The field contains the value returned by the last AP read access. There are two ways to retrieve the value returned by an AP read access:

• – perform a second read access to the same address, which initiates a new transaction on the corresponding bus, or
• – read the value returned by the last AP read access from the DP_RDBUFF register, in which case no new AP transaction occurs

Debug port target identification register (DP_TARGETSEL)

Address offset: 0xC

Reset value: 0xXXXX XXXX

Bits 31:28 TINSTANCE[3:0] : Target instance number

The field defines the instance number for the target device in a multi-drop system. It must be programmed with the same value as TINSTANCE field of DP_DLPIDR register, in order to select this device.

Bits 27:12 TPARTNO[15:0] : Target part number

The field defines the part number for the target device. It must be programmed with the same value as TPARTNO field of DP_TARGETID register, in order to select this device.

Bits 11:1 TDESIGNER[10:0] : Target designer JEDEC code

The field defines the JEDEC code for the target device. It must be programmed with the same value as TDESIGNER field of DP_TARGETID register, in order to select this device.

Bit 0 Reserved, must be kept at reset value.

66.4.4 Debug port register map

These registers are not on the CPU memory bus, they are only accessed through SW-DP and JTAG-DP debug interface.

The debug port address offset is 4 bits wide, where the 2 most significant bits are defined in the JTAG-DP register DPACC or SW-DP packet request A[3:2] field. The 2 least significant bits are 00.

Table 772. Debug port register map and reset values

Table 772. Debug port register map and reset values (continued)

1. 1. DPBANKSEL[3:0] = 0x0
2. 2. DPBANKSEL[3:0] = 0x1
3. 3. DPBANKSEL[3:0] = 0x2
4. 4. DPBANKSEL[3:0] = 0x3

66.5 Access ports

Figure 1007. Debug and access port connections

graph LR
    JTAG_SWD[JTAG/SWD] <--> SWJ_DP[SWJ-DP]
    SWJ_DP <--> DAPBUS[DAPBUS]
    DAPBUS --> AP1[AP1
(AHB-AP)]
    DAPBUS --> AP0[AP0
(APB-AP)]
    AP1 <--> CortexM7[Cortex-M7 (AHBD port)]
    AP0 <--> SystemDebugBus[System Debug Bus (APB-D)]
    

Access ports (AP) attached to the DP:

1. 1. AP1: Cortex-M7 access port (AHB-AP). Allows access to the debug and trace features integrated in the Cortex-M7 processor core via an AHB-Lite bus connected to the AHBD port of the processor.
2. 2. AP0: System access port (APB-AP). Allows access to the debug and trace features on the system APB debug bus, that is, all components not included in the processor core.

All access ports are of MEM-AP type, that is, the debug and trace component registers are mapped in the address space of the associated debug bus. The AP is seen by the debugger as a set of 32-bit registers organized in banks of four registers each. Some of these registers are used to configure or monitor the AP itself, while others are used to perform a transfer on the bus. The AP registers are listed in Table 773 .

The address of the AP registers is composed of:

• • bits [7:4]: content of the DP_SELECT register's APBANKSEL field
• • bits [3:2]: content of the A(3:2) field of the APACC data register in the JTAG-DP (see Table 770 ) or of the SW-DP Packet Request (see Table 767 ), depending on the debug interface used
• • bits [1:0]: Always set to 0

The content of the SELECT register APSEL field in the DP defines which MEM-AP is being accessed.

The debugger can access the AP registers as follows:

1. 1. Program the DP_SELECT register's APSEL field to choose one of the APs, and the APBANKSEL field to select the register bank to be accessed.
2. 2. Program the A(3:2) field in the APACC register, if using JTAG, with the register address within the bank. Program the RnW bit to select a read or a write. In the case of a write, program the DATA field with the write data. If using SWD, the A(3:2) and RnW fields are part of the Packet Request word sent to the SW-DP with the APnDP bit set (see Table 767 ). The write data is sent in the data phase.

The debugger can access the memory mapped debug component registers through the MEM-AP registers (using the AP register access procedure described above) as follows:

1. 1. Program the transaction target address in the TAR register.
2. 2. Program the CSW register, if necessary, with the transfer parameters (AddrInc for example).
3. 3. Write to or read from the DRW register to initiate a bus transaction at the address held in the TAR register. Alternatively, a read or write to banked data register BD _n triggers an access to address \( TAR[31:4] + n \) (this allows an access to the next four consecutive addresses without changing the address in the TAR register).

For more detailed information on the MEM-AP, refer to the Arm ^® Debug Interface Architecture Specification [ 1 ].

66.5.1 MEM-AP registers

Table 773. MEM-AP registers

Table 773. MEM-AP registers

Access port control/status word register (AP_CSW)

Address offset: 0x0

Reset value: 0x0000 0002 (APB-AP), 0x4000 0002 (AHB-AP)

Bit 31 Reserved, must be kept at reset value.

Bit 30 SPROT : Secure transfer request bit

In the APB-AP, this field is reserved. In the AHB-APs, this field sets the protection attribute HPROT[6] of the bus transfer.

0: Reserved.

1: Non-secure transfer.

Bit 29 Reserved, must be kept at reset value.

Bits 28:24 PROT[4:0] : Bus transfer protection bits

In the APB-AP, this field is reserved. In the AHB-APs, this field sets the protection attributes HPROT[4:0] of the bus transfer.

0bXXXX0: Instruction fetch

0bXXXX1: Data access

0bXXX0X: User mode

0bXXX1X: Privileged mode

0bXX0XX: Non-bufferable

0bXX1XX: Bufferable

0bX0XXX: Non-cacheable

0bX1XXX: Cacheable

0b0XXXX: Non-exclusive

0b1XXXX: Exclusive

Bit 23 SPISTATUS : Status of SPIDEN authentication signal

This bit determines whether the debugger can access secure memory. This field is reserved in the APB-AP.

0: Secure AHB transfers are not supported

1: Not used

Bits 22:12 Reserved, must be kept at reset value.

Bits 11:8 MODE[3:0] : Barrier support enabled bit

These bits define if the memory barrier operation is supported.

0x0: Not supported

Bit 7 TRINPROG : Transfer in progress

This bit indicates that an AP bus transfer is in progress.

0: No transfer in progress.

1: Bus transfer in progress.

Bit 6 DEVICEEN : Device Enable bit

This bit defines whether the AP can be accessed or not.

1: AP access enabled.

Bits 5:4 ADDRINC[1:0] : Auto-increment mode bits

These bits define whether the TAR address is automatically incremented after a transaction.

0x0: no auto-increment

0x1: Address is incremented by the size in bytes of the transaction (SIZE field).

0x2: Packed transfers enabled (Only in AHB-APs - reserved in APB-AP). A 32-bit AP access generates a 1 x 32-bit, 2 x 16-bit or 4 x 8-bit bus transaction corresponding to the programmed transaction size. The data is packed or unpacked accordingly.

0x3: Reserved

Bit 3 Reserved, must be kept at reset value.

Bits 2:0 SIZE[2:0] : Size of next memory access transaction (only for AHB-APs)

0x0: Byte (8-bit)

0x1: Half-word (16-bit)

0x2: Word (32-bit)

0x3-0x7: Reserved

For APB-AP, this field is read-only and fixed at 0x2 (32-bit).

Address offset: 0x04

Reset value: 0x0000 0000

Address offset: 0x0C

Reset value: 0x0000 0000

In write mode, this is the write data value. In read mode, this is the read data value.

Address offset: 0x10

Reset value: 0x0000 0000

AP banked data register 1 (AP_BD1)

Address offset: 0x14

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : read/write data for current transfer
The transaction address is TAR[31:4] << 4 + 0x4.

AP banked data register 2 (AP_BD2)

Address offset: 0x18

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : read/write data for current transfer
The transaction address is TAR[31:4] << 4 + 0x8.

AP banked data register 3 (AP_BD3)

Address offset: 0x1C

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : read/write data for current transfer
The transaction address is TAR[31:4] << 4 + 0xC.

Access port base address register (AP_BASE)

Address offset: 0xF8

Reset value: 0xE00F E003 (AP1), 0xE00E 0003 (AP0)

Bits 31:12 BASEADDR[19:0] : Base address (bits 31 to 12) of the AP ROM table

The 12 LSBs are zero since the ROM table must be aligned on a 4 Kbyte boundary.

AP1 (Cortex-M7 AHB-AP): 0xE00FE

AP0 (System APB-AP): 0xE00E0

Bits 11:2 Reserved, must be kept at reset value.

Bit 1 FORMAT : Base address register format

1: Arm ^® debug interface v5.

Bit 0 ENTRYPRESENT : Debug component present status bit

This bit indicates that debug components are present on the access port bus:

1: Debug components are present

Access port identification register (AP_IDR)

Address offset: 0xFC

Reset value: 0x8477 0001 (AP1), 0x5477 0002 (AP0)

Bits 31:28 REVISION[3:0] : Arm core revision

0x5: r1p0 (AP0)

0x8: r0p9 (AP1)

Bits 27:24 JEDECBANK[3:0] : JEDEC bank

0x4: Arm ^®

Bits 23:17 JEDECCODE[6:0] : JEDEC code

0x3B: Arm ^®

Bit 16 MEMAP : Memory access port

1: Standard register map

Bits 15:8 Reserved, must be kept at reset value.

Bits 7:0 IDENTITY[7:0] : AP type identification

0x01: AHB-AP (AP1)

0x02: APB-AP (AP0)

66.5.2 Access port register map

These registers are not on the CPU memory bus, they are only accessed through SW-DP and JTAG-DP debug interfaces.

The access port address is 8-bit wide, defined by DP_SELECTR.APBANKSEL[3:0] field and by JTAG-DP register DPACC or SW-DP packet request A[3:2] field.

Table 774. Access port register map and reset values

66.6 Trace and debug subsystem functional description

The trace and debug subsystem features the following CoreSight components:

• • System ROM tables
• • System cross-trigger interface (CTI)
• • Cross-trigger matrix (CTM)
• • Trace port interface unit (TPIU)
• • Trace bus funnel (CSTF)
• • Embedded trace FIFO (ETF)
• • Serial wire output (SWO)

These components are accessible by the debugger via the system APB-AP and its associated APB-D debug bus. They are also accessible by the Cortex-M7 processor.

The MCU debug unit (DBGMCU) is also accessed via the APB-D. This component contains registers for configuring the device behavior in Debug mode.

A trace bus replicator branches the trace bus from the CPU's ITM CoreSight component to ETF and SWO, through trace bus funnels.

66.6.1 System ROM tables

There are two ROM tables on the APB-D bus. The ROM table is a CoreSight component that contains the base addresses of all the CoreSight components on the APB-D bus. These tables allow a debugger to discover the topology of the CoreSight components automatically.

The first table points to the second table, and to the CoreSight components located in D3 power domain: SWO, DBGMCU. The table occupies a 4-Kbyte, 32-bit wide chunk of the APB-D address space, from 0xE00E0000 to 0xE00E0FFC when accessed by the debugger, and from 0x5C000000 to 0x5C000FFC when accessed from the system bus.

Table 775. System ROM table 1

The second table occupies a 4-Kbyte, 32-bit wide chunk of APB-D address space, from 0xE00F0000 to 0xE00F0FFC when accessed by the debugger, and from 0x5C010000 to 0x5C010FFC when accessed from the system bus.

Table 776. System ROM table 2

The top of each ROM table contains a number of read-only registers, including the standard CoreSight component and peripheral identity registers, see section System ROM registers .

Each debug component occupies one or more 4 Kbyte blocks of address space. This block of address space is referred to as the debug register file for the component.

The component address offset field of a ROM Table entry points to the start of the last 4 Kbyte block of the address space of the component. This block always contains the component and peripheral ID registers for the component, starting at offset 0xFD0 from the start of the block. The 4 Kbyte count field PIDR4 [7:4], specifies the number of 4 Kbyte blocks for the component. Therefore, the process for finding the start of the address space for a component is:

1. 1. Read the ROM-table entry for the component and extract its Address_Offset [18:0] from bits [31:12] of the ROM-table entry.
2. 2. Use the address offset, together with the base address of the ROM table, ROM_Base_Address, to calculate the base address of the component:

The Component_Base_Address is the start address of the 4 Kbyte block of the address space for the component.

1. 3. Read the peripheral ID4 register for the component. The address of this register is:
   \[ \text{Peripheral\_ID4\_address} = \text{Component\_Base\_Address} + 0\text{xFD0} \]
2. 4. Extract the 4 Kbyte count field [7:4] from the value of the Peripheral ID4 Register.
3. 5. Use the 4 Kbyte count field value to calculate the start address of the address space for the component. If the field value is 0b0000, which corresponds to a count value of 1, the address space for the component starts at Component_Base_Address obtained at stage 2.

The topology for the CoreSight components on the APB-D is shown in Figure 1008 .

Figure 1008. APB-D CoreSight component topology

For more information on the use of the ROM table, refer to the Arm ^® Debug Interface Architecture Specification [1].

66.6.2 System ROM registers

SYSROM memory type register (SYSROM_MEMTYPE)

Address offset: 0xFCC

Reset value: 0x0000 0000

Bits 31:1 Reserved, must be kept at reset value.

Bit 0 SYSTMEM : System memory

0: No system memory is present on this bus

SYSROM CoreSight peripheral identity register 4 (SYSROM_PIDR4)

Address offset: 0xFD0

Reset value: 0x0000 0000

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:4 SIZE[3:0] : Register file size

0x0: Register file occupies a single 4 Kbyte region

Bits 3:0 JEP106CON[3:0] : JEP106 continuation code

0x0: STMicroelectronics JEDEC continuation code

SYSROM CoreSight peripheral identity register 0 (SYSROM_PIDR0)

Address offset: 0xFE0

Reset value: 0x0000 0085 (System ROM table 1), 0x0000 0001 (System ROM table 2)

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 PARTNUM[7:0] : Device part number field, bits [7:0]
0x85: STM32H7Rx/7Sx device (System ROM table 1)
0x01: (System ROM table 2)

SYSROM CoreSight peripheral identity register 1 (SYSROM_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 0004 (System ROM table 1), 0x0000 00000 (System ROM table 2)

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:4 JEP106ID[3:0] : JEP106 identity code field, bits [3:0]
0x0: STMicroelectronics JEDEC code

Bits 3:0 PARTNUM[11:8] : Device part number field, bits [11:8]
0x4: STM32H7Rx/7Sx (System ROM table 1)
0x0: (System ROM table 2)

SYSROM CoreSight peripheral identity register 2 (SYSROM_PIDR2)

Address offset: 0xFE8

Reset value: 0x0000 001A (system ROM table 1), 0x0000 000A (system ROM table 2)

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:4 REVISION[3:0] : Device revision number
0x1: (system ROM table 1)
0x0: (system ROM table 2)

Bit 3 JEDEC : JEDEC assigned value
1: Designer ID specified by JEDEC

Bits 2:0 JEP106ID[6:4] : JEP106 identity code field, bits [6:4]
0x2: STMicroelectronics JEDEC code

SYSROM CoreSight peripheral identity register 3 (SYSROM_PIDR3)

Address offset: 0xFEC

Reset value: 0x0000 0000

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:4 REVAND[3:0] : Metal fix version

0x0: No metal fix

Bits 3:0 CMOD[3:0] : Customer modified

0x0: No customer modifications

SYSROM CoreSight component identity register 0 (SYSROM_CIDR0)

Address offset: 0xFF0

Reset value: 0x0000 000D

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 PREAMBLE[7:0] : Component ID field, bits [7:0]

0x0D: Common ID value

SYSROM CoreSight component identity register 1 (SYSROM_CIDR1)

Address offset: 0xFF4

Reset value: 0x0000 0010

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:4 CLASS[3:0] : Component ID field, bits [15:12] - component class
0x1: ROM table component

Bits 3:0 PREAMBLE[11:8] : Component ID field, bits [11:8]
0x0: Common ID value

SYSROM CoreSight component identity register 2 (SYSROM_CIDR2)

Address offset: 0xFF8

Reset value: 0x0000 0005

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 PREAMBLE[19:12] : Component ID field, bits [23:16]
0x05: Common ID value

SYSROM CoreSight component identity register 3 (SYSROM_CIDR3)

Address offset: 0xFFC

Reset value: 0x0000 00B1

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 PREAMBLE[27:20] : Component ID field, bits [31:24]
0xB1: Common ID value

66.6.3 System ROM register map and reset values

Table 777. System ROM table 1 register map and reset values

66.6.4 Cross trigger interfaces (CTI) and matrix (CTM)

The cross trigger interfaces (CTI) and cross trigger matrix (CTM) together form the CoreSight embedded cross trigger feature. There are two CTI components, one at system level and one dedicated to the Cortex-M7. The two CTIs are connected to each other via the CTM. The system-level CTI is accessible to the debugger via the system access port and associated APB-D. The Cortex-M7 CTI is physically integrated in the Cortex-M7 core, and is accessible via the Cortex-M7 access port and associated AHBD.

Figure 1009. Embedded cross trigger

The CTIs allow events from various sources to trigger debug and/or trace activity. For example, a transition detected on an external trigger input can start code trace.

Each CTI has up to 8 trigger inputs and 8 trigger outputs. Any input can be connected to any output, on the same CTI, or on another CTI via the CTM.

The trigger input and output signals for each CTI are listed in Table 779 to Table 782 .

Table 781. Cortex-M7 CTI inputs (continued)

Table 782. Cortex-M7 CTI outputs

There are four event channels in the cross trigger matrix, which allows up to four parallel bidirectional connections between trigger inputs and outputs on different CTIs. To connect input number m on CTI x to output number n on CTI y , the input must be connected to an event channel p using the CTIINEN m register of CTI x . The same channel p must be connected to the output using the CTIOUTEN n register of CTI y . Note: this applies even if the input and output belong to the same CTI.

An input can be connected to more than one channel (up to four), so an input can be routed to several outputs. Similarly, an output can be connected to several inputs. It is also possible to connect several inputs/outputs to the same channel.

Figure 1010. Mapping of trigger inputs to outputs

For more information on the cross-trigger interface CoreSight component, refer to the Arm ^® CoreSight ^™ SoC-400 Technical Reference Manual [2].

66.6.5 CTI registers

The register file base address for each CTI is defined by the ROM table for the bus to which it is connected. The registers are the same for each CTI.

CTI control register (CTI_CONTROL)

Address offset: 0x000

Reset value: 0x0000 0000

Bits 31:1 Reserved, must be kept at reset value.

Bit 0 GLBEN : Global enable.

0: Cross-triggering disabled

1: Cross-triggering enabled

CTI trigger acknowledge register (CTI_INTACK)

Address offset: 0x010

Reset value: 0x0000 0000

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 INTACK[7:0] : Trigger acknowledge

There is one bit of the register for each CTITRIGOUT output. When a 1 is written to a bit in this register, the corresponding CTITRIGOUT output is acknowledged, causing it to be cleared.

CTI application trigger set register (CTI_APPSET)

Address offset: 0x014

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 APPSET[3:0] : Set channel event

Read:

• 0bXXX0: Channel 0 event inactive
• 0bXXX1: Channel 0 event active
• 0bXX0X: Channel 1 event inactive
• 0bXX1X: Channel 1 event active
• 0bX0XX: Channel 2 event inactive
• 0bX1XX: Channel 2 event active
• 0b0XXX: Channel 3 event inactive
• 0b1XXX: Channel 3 event active

Write:

• 0bXXX0: No effect
• 0bXXX1: Set event on Channel 0
• 0bXX0X: No effect
• 0bXX1X: Set event on Channel 1
• 0bX0XX: No effect
• 0bX1XX: Set event on Channel 2
• 0b0XXX: No effect
• 0b1XXX: Set event on Channel 3

CTI application trigger clear register (CTI_APPCLEAR)

Address offset: 0x018

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 APPCLEAR[3:0] : Clear channel event

0bXXX0: No effect
0bXXX1: Clear event on Channel 0
0bXX0X: No effect
0bXX1X: Clear event on Channel 1
0bX0XX: No effect
0bX1XX: Clear event on Channel 2
0b0XXX: No effect
0b1XXX: Clear event on Channel 3

CTI application pulse register (CTI_APPPULSE)

Address offset: 0x01C

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 APPPULSE[3:0] : Pulse channel event

This register clears itself immediately.
0bXXX0: No effect
0bXXX1: Generate pulse on Channel 0
0bXX0X: No effect
0bXX1X: Generate pulse on Channel 1
0bX0XX: No effect
0bX1XX: Generate pulse on Channel 2
0b0XXX: No effect
0b1XXX: Generate pulse on Channel 3

CTI trigger IN x enable register (CTI_INENx)

Address offset: 0x0A0 + 0x4 * x, (x = 0 to 7)

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 TRIGINEN[3:0] : Cross-trigger event enable

Enables or disables a cross-trigger event on each of the four channels when CTITRIGINx is activated (x = 0 to 7).

0bXXX0: Trigger n does not generate events on Channel 0

0bXXX1: Trigger n generates events on Channel 0

0bXX0X: Trigger n does not generate events on Channel 1

0bXX1X: Trigger n generates events on Channel 1

0bX0XX: Trigger n does not generate events on Channel 2

0bX1XX: Trigger n generates events on Channel 2

0b0XXX: Trigger n does not generate events on Channel 3

0b1XXX: Trigger n generates events on Channel 3

CTI trigger OUT x enable register (CTI_OUTENx)

Address offset: 0x0A0 + 0x4 * x, (x = 0 to 7)

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 TRIGOUTEN[3:0] : Enable trigger upon event

For each channel, the field defines whether an event on that channel generates a trigger on CTITRIGOUTx (x = 0 to 7).

0bXXX0: Channel 0 events do not generate triggers on Trigger output n

0bXXX1: Channel 0 events generate triggers on Trigger output n

0bXX0X: Channel 1 events do not generate triggers on Trigger output n

0bXX1X: Channel 1 events generate triggers on Trigger output n

0bX0XX: Channel 2 events do not generate triggers on Trigger output n

0bX1XX: Channel 2 events generate triggers on Trigger output n

0b0XXX: Channel 3 events do not generate triggers on Trigger output n

0b1XXX: Channel 3 events generate triggers on Trigger output n

CTI trigger IN status register (CTI_TRGISTS)

Address offset: 0x130

Reset value: 0x0000 0000

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 TRIGINSTATUS[7:0] : Trigger input status

There is one bit of the register for each CTITRIGIN input. When a bit is set to 1 it indicates that the corresponding trigger input is active. When it is set to 0, the corresponding trigger input is inactive.

CTI trigger OUT status register (CTI_TRGOSTS)

Address offset: 0x134

Reset value: 0x0000 0000

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 TRIGOUTSTATUS[7:0] : Trigger output status

There is one bit of the register for each CTITRIGOUT output. When a bit is set to 1 it indicates that the corresponding trigger output is active. When it is set to 0, the corresponding trigger output is inactive.

CTI channel IN status register (CTI_CHINSTS)

Address offset: 0x138

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 CHINSTATUS[3:0] : Channel input status

There is one bit of the register for each channel input. When a bit is set to 1 it indicates that the corresponding channel input is active. When it is set to 0, the corresponding channel input is inactive.

CTI channel OUT status register (CTI_CHOUTSTS)

Address offset: 0x13C

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 CHOUTSTATUS[3:0] : Channel output status

There is one bit of the register for each channel output. When a bit is set to 1 it indicates that the corresponding channel output is active. When it is set to 0, the corresponding channel output is inactive.

CTI channel gate register (CTI_GATE)

Address offset: 0x140

Reset value: 0x0000 000F

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 GATEEN[3:0] : Channel output enable

For each channel, defines whether an event on that channel can propagate over the CTM to other CTIs.

0bXXX0: Channel 0 events do not propagate

0bXXX1: Channel 0 events propagate

0bXX0X: Channel 1 events do not propagate

0bXX1X: Channel 1 events propagate

0bX0XX: Channel 2 events do not propagate

0bX1XX: Channel 2 events propagate

0b0XXX: Channel 3 events do not propagate

0b1XXX: Channel 3 events propagate

CTI claim tag set register (CTI_CLAIMSET)

Address offset: 0xFA0

Reset value: 0x0000 000F

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 CLAIMSET[3:0] : Set claim tag bits

Write:

0000: No effect

xxx1: Set bit 0

xx1x: Set bit 1

x1xx: Set bit 2

1xxx: Set bit 3

Read:

0xF: Indicates there are four bits in claim tag

CTI claim tag clear register (CTI_CLAIMCLR)

Address offset: 0xFA4

Reset value: 0x0000 0000

Bits 31:4 Reserved, must be kept at reset value.

Bits 3:0 CLAIMCLR[3:0] : Reset claim tag bits

Write:

0000: No effect

xxx1: Clear bit 0

xx1x: Clear bit 1

x1xx: Clear bit 2

1xxx: Clear bit 3

Read: Returns current value of claim tag

CTI lock access register (CTI_LAR)

Address offset: 0xFB0

Reset value: 0xXXXX XXXX

Bits 31:0 ACCESS_W[31:0] : CTI register write access enable

Enables write access to some CTI registers by processor core (debuggers do not need to unlock the component)

0xC5ACCE55: Enable write access

Other values: Disable write access

CTI lock status register (CTI_LSR)

Address offset: 0xFB4

Reset value: 0x0000 0003