65. Debug infrastructure

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

65.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 65.7 .

65.3 Debug infrastructure functional description

65.3.1 Debug infrastructure block diagram

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

Figure 856. Block diagram of debug infrastructure

65.3.2 Debug infrastructure powering, clocking and reset

Power domains

Figure 857. Power domains of debug infrastructure

The debug components are distributed across the power domains D1 and D3. The D3 power domain is always considered 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 other power domain is switched off. In addition, it contains the DBGMCU and the serial wire trace features.

The D1 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 858. 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 DAPCLK domain, which covers the rest of the SWJ-DP and the access ports. The DBGMCU and System ROM table 1 are also in the DAPCLK domain.

CK_DBG_D3 clocks the SWO.

Both DAPCLK and CK_DBG_D3 are gated versions of the D3 domain system clock (rcc_hclk4).

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

TRACECLK is the trace port output clock. It is a gated version of the system clock (sys_ck), except when the PLL1 is the source for the system clock. In this case, TRACECLK is derived directly from the pll1_r_ck output. This is required in order to support the high data throughput on the trace port when the processor operates at its maximum frequency.

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 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 65.5.7

Reset of debug infrastructure

The debug components, except for the debug port 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 D3 domain only.

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

65.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 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 ones),....

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.

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 614. Packet request

Table 615. ACK response

Table 616. Data transfer

Figure 859 shows successful write and read transfers.

Figure 859. 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.

JTAG debug port

Figure 860. JTAG TAP state machine

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

The JTAG-DP implements a TAP state machine (TAPSM) based on IEEE 1149.1-1990. The state machine is shown in Figure 860 . 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 617 .

Table 617. JTAG-DP data registers

Table 617. 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 Table 618.

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

Table 618. Debug port registers

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

Debug port identification register (DP_DPIDR)

Address offset: 0x00

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 CTRL/STAT register's STICKYORUN bit

Bit 3 WDERRCLR : Write data error clear bit

0: No effect

1: Clear CTRL/STAT register's WDATAERR bit

• Bit 2 STKERRCLR : Sticky error clear bit
  • 0: No effect
  • 1: Clear CTRL/STAT register's STICKYERR bit
• Bit 1 STKCMPCLR : Sticky compare clear bit
  • 0: No effect
  • 1: Clear CTRL/STAT 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_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 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_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.

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

Bit 7 WDATAERR : Write data error in SW-DP

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.

Bit 6 READOK : AP read response in SW-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.

Bit 5 STICKYERR : Transaction error (read-only in SW-DP, R/W 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.

Bit 4 STICKYCMP : Compare match (read-only in SW-DP, R/W in JTAG-DP)

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.

Bits 3:2 TRNMODE[1:0] : Transfer mode for AP write operations

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.

Bit 1 STICKYORUN : Overrun (read-only in SW-DP, R/W in JTAG-DP)

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.

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: 0x0483 0041

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

0x0: revision 1

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

0x4830: STM32H72x/3x

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: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 - D3 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, 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

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.

65.4.2 Access ports

Figure 861. 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 <--> CortexM7[Cortex-M7 AHBD port]
    AP1 <--> D3AHB[D3 AHB interconnect]
    AP2 <--> SystemDebugBus[System Debug Bus APB-D]
  

Access ports (AP) 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: D3 access port (AHB-AP). Allows access to the bus matrix in the D3 domain. This gives visibility of the D3 domain memory and peripherals when the D1 and D2 domains are 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 619 .

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 617 ) or of the SW-DP Packet Request (see Table 614 ), 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 614 ). 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 BDn 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]. To use the MEM-AP to connect the debug port to the debug components (in the example, a processor, an ETM and a ROM table), go to Section 65.4.2: Access ports .

MEM-AP registers

Table 619. 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.

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 option bit

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

0: Secure AHB transfers are blocked

1: Secure AHB transfers are allowed

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

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 the AP ROM table

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

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

AP1 (D3 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 are not present (AP1)

1: Debug components are 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)

0x11: Reserved

65.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 device behavior in Debug mode.

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

65.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 D3 power domain: SWO. 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 620. 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 621. 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 862 .

Figure 862. APB-D CoreSight component topology

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 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 4KCOUNT[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 0083 (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]

0x83: STM32H7 device (System ROM table 1)

0x01: STM32H7 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 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: STM32H7 device System ROM table 1

0x0: STM32H7 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 622. System ROM table 1 register map and reset values

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

65.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 863. 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 624 to Table 627 .

Table 626. Cortex-M7 CTI inputs (continued)

Table 627. 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 = p \) register of CTI \( x \) . The same channel \( p \) must be connected to the output using the CTIOUTEN \( n = p \) 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 864. 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 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: 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).

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 + 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).

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

Address offset: 0xFA0

Reset value: 0x0000 000F

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

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

Address offset: 0xFA4

Reset value: 0x0000 0000

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

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

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 is permitted

1: Write access is 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 exists

1: Lock control mechanism is 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: 4 channels

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

0x8: 8 trigger inputs and 8 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: 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 modifications

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 628. CTI register map and reset values