64. Debug infrastructure

64.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 (SWD) access port, using industry standard debugging tools. A trace port allows data to be captured for logging and analysis.

The trace and debug system has been 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 port. This allows breakpoint and watchpoint setting, code stopping, memory access.

• • 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 information packet.

• • Capturing trace continuously 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 a debugger command, a software command, an external trigger signal or an internal event for example.

• • 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, the software, an external trigger or an internal event for example.

• • Reading the buffer with the debugger

The debugger can read the content 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 either read by the processor core, or transferred into the system memory by DMA. This powerful feature allows built-in test software to monitor code execution in real time, to analyze and identify faults or to autonomously handle exceptions.

• • Uploading stored trace

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

64.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 (SWD) 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:

• • SWJ-DP: JTAG/Serial-wire debug port
• • AXI-AP: AXI access port
• • AHB-AP: AHB access port
• • APB-AP: APB access port
• • ITM: instrumentation trace macrocell
• • DWT: data watchpoint and trace
• • ETM: embedded trace macrocell
• • ETF: embedded trace FIFO
• • TPIU: trace port interface unit
• • SWO: serial-wire output
• • CTI: cross trigger interface
• • CSTF: trace bus funnel

Detailed information is available in the Arm documents referenced in Section 64.7 .

64.3 Debug infrastructure functional description

64.3.1 Debug infrastructure block diagram

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

64.3.2 Debug infrastructure pins and internal signals

Table 528. JTAG/Serial-wire debug port pins

1. 1. TRACESWO is multiplexed with JTDO. This means that single-wire trace is only available when using the serial-wire debug interface, not when using JTAG.

1. 1. TRGIO can be configured as an input or an output by the TRGOEN bit in the MCU debug unit (DBGMCU). If configured as an input, it is connected to TRGIN. If configured as an output, it is connected to TRGOUT. This is because TRGIN and TRGOUT are not available on certain packages.

64.3.3 Debug infrastructure powering, clocking and reset

Power domains

Figure 764. Power domains of debug infrastructure

The debug components are distributed across the power CPU domain (CD) and SmartRun domain (SRD). The SmartRun power domain must be always on when the debugger is connected. It therefore contains the SWJ-DP, so that the debugger does not lose the connection with the SoC when the CPU power domain is switched off. In addition, it contains the MCU debug unit (DBGMCU) and the serial-wire trace features.

The CPU power domain contains the Cortex-M7 core and the associated debug and trace components. It also contains the system trace components located on the APB-D. This power domain therefore needs to be on whenever a debug access to the Cortex-M7 is required or whenever a trace functionality is active on the processor.

Clock domains

Figure 765. 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 modes, 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 DAPCLK domain, which covers the rest of the SWJ-DP and the access ports. The DBGMCU and a ROM table are also in the DAPCLK domain.

CK_DBG_SRD clocks the SWO.

Both DAPCLK and CK_DBG_SRD are gated versions of the SmartRun domain system clock (rcc_fclk_srd).

CK_DBG_CD clocks the trace components in the CPU power domain: a ROM table, CoreSight trace funnel, ETF, system CTI, TPIU, as well as the ATB trace bus. It is a gated version of the CPU domain system clock (rcc_aclk).

TRACEPORTCK clocks the trace port interfaces (TRACECLK, TRACED1 to 4 and TRACESWO). It is selected through SW[2:0] bitfield of RCC_CFGR register.

All the debug clocks (except DAPCLK) can be enabled and disabled by register bits in the DBGMCU. The DAPCLK domain is enabled by the debugger using the CDBGPWRUPREQ bit in the debug port CTRL/STAT register. The clock must be enabled before the debugger can access any of the debug features on the device. It must be disabled at power up and when the debugger is disconnected, to avoid wasting energy.

The debug and trace components included in the processor (such as ETM, ITM, DWG, FPB) are clocked with the CPU clock (rcc_cpu_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 DBGMCU. For more information, refer to Section 64.5.7 .

Reset of debug infrastructure

The debug components, except for the debug and access ports, are reset by their respective power domain resets. The debug port (SWJ-DP) is reset by a power-on reset of the SmartRun domain only.

64.4 Debug access port functional description

The debug access port (DAP) is a debug subsystem comprising Serial-wire and JTAG debug port (SWJ-DP) and three access ports.

64.4.1 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 I/O pins.

By default, the JTAG-DP is selected upon a system or power-on reset. The five I/Os 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),...,0,1,1,1,1,0,0,1,1,1,1,0,0,1,1,1,....(50 or more),...

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 I/Os can be reconfigured to other functions by software. In that case, debugging is no longer possible.

Serial-wire debug port

The Serial-wire debug protocol uses two pins:

• • SWCLK: clock from host to target
• • SWDIO: bi-directional serial data (100 k \( \Omega \) pull-up required)

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 case of a write) or target (in case of a read)

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

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

Table 532. Packet request

Table 533. ACK response

Table 534. Data transfer

The figure below shows successful write and read transfers.

Figure 766. SWD successful data transfer

In the case of a FAULT or WAIT ACK response from the target, the data transfer phase is canceled, unless overrun detection is enabled. In this case the data are ignored by the target (in case of a write), or not driven (in 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.

JTAG debug port

Figure 767. JTAG TAP state machine

stateDiagram-v2
    [*] --> Test-Logic-Reset
    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
    Select-DR-Scan --> Capture-DR : J
    Capture-DR --> Shift-DR : J
    Shift-DR --> Exit-DR : JTMS=1
    Exit-DR --> Run-Test/Idle
  

The JTAG-DP implements a TAP state machine (TAPSM) based on IEEE 1149.1-1990. The state machine is shown in the previous figure. 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 onto 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 into the IR scan chain is transferred into 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 are selected.

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

When the TAPSM goes through the Update-DR state, the value scanned into the DR scan chain is transferred into 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 the table below.

Table 535. JTAG-DP data registers

Table 535. JTAG-DP data registers (continued)

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

Debug port registers

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

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.
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 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 532). The write data is sent in the data phase.

Table 536. Debug port registers

Table 536. Debug port registers (continued)

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] : part number for the debug port

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: STICKYORUN bit cleared in CTRL/STAT register

Bit 3 WDERRCLR : write data error clear bit

0: no effect

1: WDATAERR bit cleared in CTRL/STAT register

Bit 2 STKERRCLR : sticky error clear bit

0: no effect

1: STICKYERR bit cleared in CTRL/STAT register

Bit 1 STKCMPCLR : sticky compare clear bit

0: no effect

1: STICKYCMP bit cleared in CTRL/STAT register

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: transaction aborted

Debug port control/status register (DP_CTRL/STAT)

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 CDBGIRSTACK : debug domain reset status bit - not used in this device

Bit 26 CDBGIRSTREQ : 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 at the 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_CTRL/STAT 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.

1xxx include byte lane 3 in comparisons

x1xx: include byte lane 2 in comparisons

xx1xX: include byte lane 1 in comparisons

xxx1: include byte lane 0 in comparisons

The bit indicates that:

• – There is a parity or a framing error on the data phase of a write operation
• – A write operation that has been accepted by the DP, has then be 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: an error 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: an error 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 it.

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 (new transaction received before previous transaction completed). This bit is only set if the ORUNDETECT bit is set.

0: no overrun

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

Bit 0 ORUNDETECT : overrun detection mode enable

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: 0x1048 0401

Bits 31:28 TREVISION[3:0] : target revision

0x1: revision 1

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

0x0480: STM32H7A/B

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: instance 0

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:28 APSEL[3:0] : access port select bits
These bits select the access port for the next transaction.

• 0x0: AP0 - Cortex-M7 debug access port (AHB-AP)
• 0x1: AP1 - SRD access port (AHB-AP)
• 0x2: AP2 - system debug access port (APB-AP)
• 0x3 to 0xF: reserved

Bits 27: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: CTRL/STAT 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, it initiates a new transaction on the corresponding bus.
• – 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.

64.4.2 Access ports

Figure 768. Debug and access port connections

graph LR
    JTAG_SWD[JTAG/SWD] <--> SWJ_DP[SWJ-DP]
    SWJ_DP <--> DAPBUS
    DAPBUS --> AP0[AP0
(AHB-AP)]
    DAPBUS --> AP1[AP1
(AHB-AP)]
    DAPBUS --> AP2[AP2
(APB-AP)]
    AP0 <--> Cortex_M7[Cortex-M7
(AHBD port)]
    AP1 <--> SRD_AHB[SRD AHB interconnect]
    AP2 <--> System_debug_bus[System debug bus
(APB-D)]
  

The following access ports (AP) are attached to the DP:

1. 1. AP0: 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. AP1: SRD access port (AHB-AP). Allows access to the bus matrix in the SmartRun domain. This gives visibility of the SmartRun domain memory and peripherals when the CPU domain is switched off. No CoreSight components are accessible via this port.
3. 3. AP2: 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 537 .

The address of the AP registers is composed as follows:

• • bits [7:4]: content of the APBANKSEL field in the DP_SELECT register
• • bits [3:2]: content of the A(3:2) field of the APACC data register in the JTAG-DP (see Table 535 ) or content of the SW-DP packet request (see Table 532 ), depending on the debug interface used
• • bits [1:0]: always set to 0

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

The debugger can access the AP registers as follows:

1. 1. Program the APSEL field of the DP_SELECT register to choose one of the APs, and program 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 532 ). 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 above AP register access procedure) 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 BDn triggers an access to address \( TAR[31:4] + n \) (this allows accessing up to 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].

MEM-AP registers

Table 537. 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: if SPIDEN is high, secure transfer, if SPIDEN is low, non-secure transfer

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.

xxxx0: instruction fetch

xxxx1: data access

xx0xx: user mode

xx1xx: privileged mode

x0xxx: non-bufferable

x1xxx: bufferable

x0xxx: non-cacheable

x1xxx: cacheable

0xxxx: non-exclusive

1xxxx: exclusive

Bit 23 SPSTATUS : status of SPIDEN option bit

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

0: secure AHB transfers blocked

1: secure AHB transfers allowed

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

Bits 11:8 MODE[3:0] : barrier support enabled bits

These bits define if the memory barrier operation is supported.

0x0: not supported

Bit 7 TRINPROG : transfer in progress

This bit indicates that a bus transfer is in progress on the AP.
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 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 gives rise to 1 x 32-bit, 2 x 16-bit or 4 x 8-bit bus transactions, corresponding to the programmed transaction size. The data are 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).

Access port base address register (AP_BASE)

Address offset: 0xF8

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

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

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

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

AP1 (SRD AHB-AP): 0x00000 (no ROM table present)

AP2 (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.

0: debug components not present (AP1)

1: debug components present (AP0, AP2)

Access port identification register (AP_IDR)

Address offset: 0xFC

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

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

0x5: r1p0 (AP2)

0x8: r0p9 (AP0 and 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 (AP0 and AP1)

0x02: APB-AP (AP2)

0x03-0xFF: reserved

64.5 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 non-CoreSight component contains registers for configuring the behavior of the device in debug mode.

A trace bus replicator branches the trace bus from the CPU ITM CoreSight component to ETF and SWO.

64.5.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 the SmartRun power domain: SWO. The DBGMCU is not referenced by the table as it is not a standard CoreSight component. The table occupies a 4-Kbyte, 32-bit wide chunk of 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 538. 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 539. 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 the following:

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.

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

1. 4. Extract the 4-Kbyte count field [7:4] from the value of the peripheral ID4 register.

1. 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, that corresponds to a count value of 1, the address space for the component starts at Component_Base_Address obtained at step 2.

The topology for the CoreSight components on the APB-D is shown in the figure below.

Figure 769. APB-D CoreSight component topology

MSv49700V2

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

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 SYSTEM : system memory

0: no system memory 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 4KCOUNT[3:0] : register file size

0x0: The 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 0080 (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]

0x80: STM32H7A/B device (System ROM table 1)

0x01: STM32H7A/B device (System ROM table 2)

SYSROM CoreSight peripheral identity register 1 (SYSROM_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 0004 (System ROM table 1), 0x0000 0000 (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]

0x04: STM32H7A/B device (System ROM table 1)

0x00: STM32H7A/B device (System ROM table 2)

SYSROM CoreSight peripheral identity register 2 (SYSROM_PIDR2)

Address offset: 0xFE8

Reset value: 0x0000 000A

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

Bits 7:4 REVISION[3:0] : device revision number

0x1: rev 1

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

System ROM register map and reset values

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

Table 540. System ROM table 1 register map and reset values (continued)

Table 541. System ROM table 2 register map and reset values

Table 541. System ROM table 2 register map and reset values (continued)

64.5.2 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 770. 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 or halt the processor.

Each CTI has up to eight trigger inputs and eight 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 the tables below.

Table 542. System CTI inputs

Table 542. System CTI inputs (continued)

Table 543. System CTI outputs

Table 544. Cortex-M7 CTI inputs

Table 545. Cortex-M7 CTI outputs

Table 545. Cortex-M7 CTI outputs (continued)

There are four event channels in the cross trigger matrix, that 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 that 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 771. 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].

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 this 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:

• xxx0: channel 0 event inactive
• xxx1: channel 0 event active
• xx0x: channel 1 event inactive
• xx1x: channel 1 event active
• x0xx: channel 2 event inactive
• x1xx: channel 2 event active
• 0xxx: channel 3 event inactive
• 1xxx: channel 3 event active

Write:

• xxx0: no effect
• xxx1: Sets event on channel 0.
• xx0x: no effect
• xx1x: Sets event on channel 1.
• x0xx: no effect
• x1xx: Sets event on channel 2.
• 0xxx: no effect
• 1xxx: Sets 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

xxx0: no effect

xxx1: Clears event on channel 0.

xx0x: no effect

xx1x: Clears event on channel 1.

x0xx: no effect

x1xx: Clears event on channel 2.

0xxx: no effect

1xxx: Clears 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.

xxx0: no effect

xxx1: Generates pulse on channel 0.

xx0x: no effect

xx1x: Generates pulse on channel 1.

x0xx: no effect

x1xx: Generates pulse on channel 2.

0xxx: no effect

1xxx: Generates pulse on channel 3.

CTI trigger IN x enable register (CTI_INENx)

Address offset: 0x020 + 4 * x, where 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).

xxx0: Trigger n does not generate events on channel 0.

xxx1: Trigger n generates events on channel 0.

xx0x: Trigger n does not generate events on channel 1.

xx1x: Trigger n generates events on channel 1.

x0xx: Trigger n does not generate events on channel 2.

x1xx: Trigger n generates events on channel 2.

0xxx: Trigger n does not generate events on channel 3.

1xxx: Trigger n generates events on channel 3.

CTI trigger OUT x enable register (CTI_OUTENx)

Address offset: 0x0A0 + 4 * x, where 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).

xxx0: Channel 0 events do not generate triggers on trigger output n.

xxx1: Channel 0 events generate triggers on trigger output n.

xx0x: Channel 1 events do not generate triggers on trigger output n.

xx1x: Channel 1 events generate triggers on trigger output n.

x0xx: Channel 2 events do not generate triggers on trigger output n.

x1xx: Channel 2 events generate triggers on trigger output n.

0xxx: Channel 3 events do not generate triggers on trigger output n.

1xxx: 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, this field defines whether an event on that channel can propagate over the CTM to other CTIs.

xxxX0: Channel 0 events do not propagate.

xxx1: Channel 0 events propagate.

xx0x: Channel 1 events do not propagate.

xx1x: Channel 1 events propagate.

x0xx: Channel 2 events do not propagate.

x1xx: Channel 2 events propagate.

0xxx: Channel 3 events do not propagate.

1xxx: 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: Sets bit 0.

xx1x: Sets bit 1.

x1xx: Sets bit 2.

1xxx: Sets bit 3.

Read:

1111: 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: Clears bit 0.

xx1x: Clears bit 1.

x1xx: Clears bit 2.

1xxx: Clears 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

This filed enables write access to some CTI registers by processor cores (debuggers do not need to unlock the component).

0xC5ACCE55: write access enabled

Other values: write access disabled

CTI lock status register (CTI_LSR)

Address offset: 0xFB4

Reset value: 0x0000 0003

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

Bit 2 LOCKTYPE : size of the CTI_LAR register

0: 32-bit

Bit 1 LOCKGRANT : current status of lock

This bit always returns zero when read by an external debugger.

0: write access permitted

1: write access blocked. Only read access is permitted.

Bit 0 LOCKEXIST : existence of lock control mechanism

The bit indicates whether a lock control mechanism exists. It always returns zero when read by an external debugger.

0: no lock control mechanism

1: lock control mechanism implemented

CTI authentication status register (CTI_AUTHSTAT)

Address offset: 0xFB8

Reset value: 0x0000 000A

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

Bits 7:6 SNID[1:0] : security level for secure non-invasive debug

0x0: not implemented

Bits 5:4 SID[1:0] : security level for secure invasive debug

0x0: not implemented

Bits 3:2 NSNID[1:0] : security level for non-secure non-invasive debug

0x2: disabled

0x3: enabled

Bits 1:0 NSID[1:0] : security level for non-secure invasive debug

0x2: disabled

0x3: enabled

CTI device configuration register (CTI_DEVID)

Address offset: 0xFC8

Reset value: 0x0004 0800

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

Bits 19:16 NUMCH[3:0] : number of ECT channels available

0x4: four channels

Bits 15:8 NUMTRIG[7:0] : number of ECT triggers available

0x8: height trigger inputs and height trigger outputs

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

Bits 4:0 EXTMUXNUM[4:0] : number of trigger input/output multiplexers

0x0: none

CTI device type identifier register (CTI_DEVTYPE)

Address offset: 0xFCC

Reset value: 0x0000 0014

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

Bits 7:4 SUBTYPE[3:0] : sub-classification

0x1: Indicates that this component is a cross-triggering component.

Bits 3:0 MAJORTYPE[3:0] : major classification

0x4: Indicates that this component allows a debugger to control other components in a CoreSight SoC-400 system.

CTI CoreSight peripheral identity register 4 (CTI_PIDR4)

Address offset: 0xFD0

Reset value: 0x0000 0004

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

Bits 7:4 4KCOUNT[3:0] : register file size

0x0: The register file occupies a single 4-Kbyte region.

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

0x4: Arm JEDEC code

CTI CoreSight peripheral identity register 0 (CTI_PIDR0)

Address offset: 0xFE0

Reset value: 0x0000 0006

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

Bits 7:0 PARTNUM[7:0] : part number field, bits [7:0]

0x06: CTI part number

CTI CoreSight peripheral identity register 1 (CTI_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 00B9

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

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

0xB: Arm JEDEC code

Bits 3:0 PARTNUM[11:8] : part number field, bits [11:8]

0x9: CTI part number

CTI CoreSight peripheral identity register 2 (CTI_PIDR2)

Address offset: 0xFE8

Reset value: 0x0000 005B

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

Bits 7:4 REVISION[3:0] : component revision number

0x5: r1p0

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]

0x3: Arm JEDEC code

CTI CoreSight peripheral identity register 3 (CTI_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 modification

CTI CoreSight component identity register 0 (CTI_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

CTI CoreSight component identity register 1 (CTI_CIDR1)

Address offset: 0xFF4

Reset value: 0x0000 0090

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

Bits 7:4 CLASS[3:0] : component ID field, bits [15:12] - component class
0x9: CoreSight component

Bits 3:0 PREAMBLE[11:8] : component ID field, bits [11:8]
0x0: common ID value

CTI CoreSight component identity register 2 (CTI_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

CTI CoreSight component identity register 3 (CTI_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

CTI register map and reset values

Table 546. CTI register map and reset values

Table 546. CTI register map and reset values (continued)