63. Debug infrastructure

63.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 captures data 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 one or both processors are switched off or clock-stopped.

• • Breakpoint debugging of each core independently

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

• • Synchronous debugging of both cores

When one core stops due to a breakpoint or a debugger stop command, the other core can be stopped as well. Similarly, the cores can be restarted at the same time. This allows debugging of loosely coupled applications which require the processors to remain synchronized.

• • Tracing code execution from one or both cores via the trace port

Trace information from both cores is combined into a single trace stream and output to a real-time trace port analyzer. 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 or an internal event.

• • 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 different means such as debugger, software, external trigger or internal event.

• • 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 either processor core, or transferred into system memory by DMA. This powerful feature allows built-in test software to monitor real-time

code execution, 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 communications interfaces (such as USB, USART, SPI, I2C, Ethernet or CAN). This is especially useful if the trace port is not accessible, for example remote monitoring and failure analysis of a deployed product.

63.2 Debug infrastructure features

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

• • Independent breakpoint debugging of each CPU core in the system
• • 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 63.8 .

63.3 Debug infrastructure functional description

63.3.1 Debug infrastructure block diagram

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

Figure 870. Block diagram of debug infrastructure

63.3.2 Debug infrastructure pins and internal signals

Table 615. 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 DBGMCU. If configured as an input, it is connected to TRGIN. If an output, it is connected to TRGOUT. This is because TRGIN and TRGOUT are not available on certain packages.

63.3.3 Debug infrastructure powering, clocking and reset

Power domains

Figure 871. Power domains of debug infrastructure

The debug components are distributed across the power domains D1, D2 and D3. The D3 power domain is always considered to be 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 one or both of the other power domains are switched off. In addition, it contains the timestamp generator, the DBGMCU and the serial wire trace features. This allows the Cortex-M7 core to be switched off while still allowing basic trace on the Cortex-M4.

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 that are common to both processors. 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 either processor.

The D2 domain contains only the debug and trace components dedicated to the Cortex-M4. This power domain can be switched off without any impact on Cortex-M7 debug and trace.

Clock domains

Figure 872. 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, timestamp generator and System ROM table 1 are also in the DAPCLK domain.

CK_DBG_D3 clocks the SWO and serial wire trace funnel.

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

CK_DBG_D2 is the clock for the D2 domain trace bus components. It is a gated version of the D2 domain system clock (rcc_hclk1).

TRACECLK is the trace port output clock. It is derived from the PLL1 R divider output (pll1_r_ck).

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 processors (such as ETM ITM, DWG and FPB) are clocked with the corresponding core clock (rcc_c1_ck and rcc_c2_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 63.5.8

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.

63.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 four access ports.

63.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 (100k \( \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 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 619. Packet request

Table 620. ACK response

Table 621. Data transfer

Figure 873 shows successful write and read transfers.

Figure 873. 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 will be 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 874. 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=0
    Update-DR --> Select-IR-Scan: JTMS=1
    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=0
    Update-IR --> Select-DR-Scan: JTMS=1
  

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

Table 622. JTAG-DP data registers

Table 622. 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 623.

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

Table 623. 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_PIDR)

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 (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: 0x0450 0041

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

0x0: revision 0

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

0x4500: STM32H7

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

0x020: STMicroelectronics

Bit 0 Reserved, set to 1.

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: AP3 - Cortex-M4 debug access port (AHB-AP)

0x4 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

Reset value: N/A

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.

63.4.2 Access ports

Figure 875. Debug and access port connections

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

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

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 one of the processor cores.
4. 4. AP3: Cortex-M4 access port (AHB-AP). Allows access to the debug and trace features integrated in the Cortex-M4 processor core via its internal AHB bus.

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

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 622 ) or of the SW-DP Packet Request (see Table 619 ), depending on the debug interface used
• • bits [1:0]: Always set to 0

The content of the SELECT register APSEL field in the DP define 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 619 ). 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 B _n 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] . 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 63.6.2 :

Cortex-M7 data watchpoint and trace unit (DWT) and Section 63.7.2: Cortex-M4 data watchpoint and trace unit (DWT).

MEM-AP registers

Table 624. 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), 0xE00F F003 (AP3)

Bits 31:12 BASEADDR[19:0] : Base address (bits 31 to 12) for the ROM AP 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

AP3 (Cortex-M4 AHB-AP): 0xE00FF

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, AP3)

Access port identification register (AP_IDR)

Address offset: 0xFC

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

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

0x2: r0p3 (AP3)

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: Cortex-M4 AHB-AP (AP3)

63.5 Trace and debug subsystem functional description

The trace and debug subsystem features the following CoreSight components:

• • System ROM tables
• • Global timestamp generator (TSG)
• • 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)
• • Serial wire output trace funnel (SWTF)

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 and Cortex-M4 processors.

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 replicators branch the trace bus from the CPU's ITM CoreSight component to ETF and SWO, through trace bus funnels.

63.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 access 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, SWTF, TSG. 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 625. System ROM table 1

Table 625. System ROM table 1 (continued)

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 626. 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 876.

Figure 876. APB-D CoreSight component topology

MSV39787V2

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 SYSEM : 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 0050 (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]

• 0x50: 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 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]

• 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

0x0: Rev 0

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 627. System ROM table 1 register map and reset values

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

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

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

63.5.2 Global timestamp generator (TSG)

The global timestamp generator contains a 64-bit counter that provides a common timing reference for all of the trace sources in the system, namely the ETM and ITM in each processor core. These components insert timestamps in the trace streams that allow the trace analyzer to recover the chronological order of trace packets, which can be lost when multiple trace sources are multiplexed into one stream at the funnels.

The TSG registers are accessible over the APB-D. This allows the debugger or debug software to:

• • start and stop the timestamp incrementing
• • read the current timestamp value
• • change the current timestamp value
  • – The timestamp counter must be halted while it is changed. When the timestamp value is changed, the timestamp generator resynchronizes all the trace sources.
• • change the reported timestamp increment

For more information on the global timestamp generator CoreSight component, refer to the Arm® CoreSight™ SoC-400 Technical Reference Manual [2].

The timestamp generator is located in the D3 power domain, and the timestamp is distributed to the Cortex-M7 and Cortex-M4. To simplify the distribution over power domain

boundaries, the 64-bit timestamp is encoded in seven bits, then decoded in the destination power domain, and interpolated to increase its resolution if the processor clock is significantly faster than the generator clock. The timestamp distribution is shown in Figure 877.

Figure 877. Global timestamp distribution

TSG registers

TSG counter control register (TSG_CNTCR)

Address offset: 0x000

Reset value: 0x0000 0000

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

Bit 1 HDBG : Halt on debug

0: Normal operation

1: Halt counter when system-wide debug state is detected - not implemented

Bit 0 EN : Enable

0: Counter disabled

1: Counter enabled and incrementing

TSG counter status register (TSG_CNTSR)

Address offset: 0x004

Reset value: 0x0000 0000

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

Bit 1 DBGH : Debug halt

0: Normal operation

1: Counter halted due to system-wide debug state

Bit 0 Reserved, must be kept at reset value.

TSG current counter value lower register (TSG_CNTCVL)

Address offset: 0x008

Reset value: 0x0000 0000

Bits 31:0 CNTCVL[31:0] : TSG current counter value field, bits[31:0]

To change the current timestamp value, write the lower 32 bits of the new value to this register before writing the upper 32 bits to CNTCVU. The timestamp value is not changed until the CNTCVU register is written to. Note: The TSG_CNTCR register's EN bit must be cleared before writing to this register.

TSG current counter value upper register (TSG_CNTCVU)

Address offset: 0x00C

Reset value: 0x0000 0000

Bits 31:0 CNTCVU[31:0] : TSG current counter value field, bits[63:32]

To change the current timestamp value, write the lower 32 bits of the new value to CNTCVL before writing the upper 32 bits to this register. The 64-bit timestamp value is updated with the value from both writes when this register is written to. Note: The TSG_CNTCR register's EN bit must be cleared before writing to this register.

TSG base frequency ID register (TSG_CNTFID0)

Address offset: 0x020

Reset value: 0x0000 0000

Bits 31:0 FREQ[31:0] : Increment frequency of TSG counter in Hz

This field must be programmed with the trace generator clock frequency whenever it changes.

TSG CoreSight peripheral identity register 4 (TSG_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

TSG CoreSight Peripheral identity register 0 (TSG_PIDR0)

Address offset: 0xFE0

Reset value: 0x0000 0001

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

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

0x01: TSG part number

TSG CoreSight peripheral identity register 1 (TSG_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 00B1

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]

0x1: TSG part number

TSG CoreSight peripheral identity register 2 (TSG_PIDR2)

Address offset: 0xFE8

Reset value: 0x0000 001B

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

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

0x1: r0p1

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

TSG CoreSight peripheral identity register 3 (TSG_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

TSG CoreSight component identity register 0 (TSG_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

TSG CoreSight component identity register 1 (TSG_CIDR1)

Address offset: 0xFF4

Reset value: 0x0000 00F0

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

Bits 7:4 CLASS[3:0] : Component ID field, bits [15:12] - component class
0xF: CoreSight Soc-400 component

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

TSG CoreSight component identity register 2 (TSG_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

TSG CoreSight component identity register 3 (TSG_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

TSG register map and reset values

Table 629. TSG register map and reset values

Table 629. TSG register map and reset values (continued)

63.5.3 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 three CTI components, one at system level, one dedicated to the Cortex-M7 and one dedicated to the Cortex-M4. The three CTIs are connected to each other via the CTM. The system-level CTI and the Cortex M4 CTI are 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 878. Embedded cross trigger

MSv39781V1

The CTIs allow events from various sources to trigger debug and/or trace activity. For example, a breakpoint reached in one of the processor cores can stop the other processor, or 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 630 to Table 635 .

Table 630. System CTI inputs

Table 631. System CTI outputs

Table 632. Cortex-M7 CTI inputs

Table 635. Cortex-M4 CTI outputs (continued)

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

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

Figure 879. Mapping of trigger inputs to outputs

Example configurations:

When either CPU core hits a breakpoint, stop the other core. Restart the two cores synchronously.

To stop both cores when either core stops requires the HALTED output of each core to be connected to the EDBGREQ input of the opposite core.

As shown in Table 632 and Table 634 , the HALTED signal from the Cortex-M7 core is connected to input 0 of the Cortex-M7 CTI, and the same signal from the Cortex-M4 core is connected to the same input on the Cortex-M4 CTI. Hence the CTIINEN0 register on each CTI is programmed such as to connect these inputs to a CTM channel (for example channel 0).

As shown in Table 633 and Table 635 , the EDBGGRQ signals to the CPUs are connected to output 0 of the respective CTIs. Therefore, the CTIOUTEN0 register of the each CTI should be programmed such as to connect these outputs to the same CTM channel.

To restart both cores simultaneously the debugger must use the APPPULSE register in either of the CTIs. This allows the debugger to generate a pulse on any of the four ETM channels. The channel must be connected to the DBGRESTART signal of both cores.

As shown in Table 633 and Table 635 , the DBGRESTART signals to the CPUs are connected to output 1 of the respective CTIs. Therefore, the CTIOUTEN1 register of the each CTI should be programmed such as to connect these outputs to an unused CTM channel (for example channel 1).

The above configuration is illustrated in Figure 880 .

Figure 880. Cross trigger configuration example

To force the processors to restart simultaneously, the debugger should use the following procedure:

1. 1. Clear the debug request by writing 0x01, then 0x00, to the CTIINTACK register in each CTI.
2. 2. Cause a pulse on channel 1 by writing 0x02 to the APPPULSE register in either CTI. This will generate a restart request to both processors.

Note that the debugger can also force both cores to stop simultaneously by writing 0x01 to the APPPULSE register in either CTI, which generates a pulse on channel 0.

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