32. Debug support (DBG)

32.1 Introduction

A comprehensive set of 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
• • 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 debug features are based on Arm ^® CoreSight ^™ components.

• • General features:
  • – SWJ-DP: JTAG/Serial-wire debug port
  • – AHB-AP: AHB access port
• • CPU2 debug features:
  • – ROM tables
  • – System control space (SCS)
  • – Breakpoint unit (BPU)
  • – Data watchpoint and Trace unit (DWT)
  • – Cross trigger interface (CTI)
• • CPU1 debug features:
  • – ROM table
  • – System control space (SCS)
  • – Breakpoint unit (FPB)
  • – Data watchpoint and Trace unit (DWT)
  • – Instrumentation trace macrocell (ITM)
  • – Cross trigger interface (CTI)
  • – Trace port interface unit (TPU)

CPU2 debug access via CPU2 AHB-AP and its associated AHB bus is disabled.

The CPU1 debug features are accessible by the debugger via the CPU1 AHB-AP.

Additional information can be found in the Arm ^® documents referenced in Section 32.19 .

32.2 Debug use cases

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 enables, among others, breakpoint and watchpoint setting, code stepping and memory access.
• • 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 the user to debug loosely coupled applications, which require the processors to remain synchronized.
• • Tracing code execution via the trace port
  Trace information from the CPU1 (Cortex®-M4) is combined into a single trace stream and sent 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.

32.3 DBG functional description

32.3.1 DBG block diagram

Figure 344. Block diagram of debug support infrastructure

1. Arm ^® CoreSight ^™ component

32.3.2 DBG pins and internal signals

Table 187. JTAG/Serial-wire debug port pins

Table 188. Single Wire Trace port pins

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

32.3.3 DBG power domains

The debug components are located in the core power domain. This means that debugger connection is not possible in shutdown or standby low power modes. To avoid losing the connection when the device enters standby mode, it is possible to maintain the power to the core by setting a bit in the DBGMCU. This keeps the processor clocks active, and holds off the reset, so that the debug session is maintained.

32.3.4 DBG clocks

The debugger supplies the clock for the debug port 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 CPU2 access port.

The DAPCLK is a gated version of the system HCLK4.

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. The availability of the clock is reflected in the CDBGPWRUPACK bit in the debug port CTRL/STAT register. The DAPCLK is disabled at power up, after OBL, and after wakeup from Standby, and must be disabled when the debugger is disconnected, to reduce power consumption.

The debug and trace components included in the processors (among them ITM, DWG, FPB) are clocked with the corresponding core clock.

32.3.5 Debug and low power modes

The devices include power saving features that allow the core power domain to be switched off or stopped when not required. If the power is switched off, or the core is not clocked, all debug components are inaccessible to the debugger. To avoid this, power saving mode emulation has been implemented. If 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, but the debugger does not lose the connection.

Emulation mode is programmed in the microcontroller debug (DBGMCU) unit. For more information refer to Section 32.8 .

32.3.6 DBG reset

The debug port (SWJ-DP) is reset by a power-on reset or an OBL reset, and when waking up from Standby mode.

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

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

Two types of interface can be configured:

• – a 5-pin standard JTAG interface (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 after a system or a power-on reset. The five IO pins are configured by hardware in debug alternative function mode. The SWJ-DP incorporates pull-up resistors on JTDI, JTMS/SWDIO, and nJTRST, as well as a pull-down resistor on JTCK/SWCLK.

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 pins JTDI, JTDO and nJTRST can be used for other functions. It should be noted that all SWJ port IOs can be reconfigured to other functions by software, but debugging is no longer possible.

32.4.1 JTAG debug port

There are two TAPs on the JTAG debug port, the JTAG-DP TAP and the BSC TAP.

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

Figure 345. JTAG TAP state machine

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

The operation of the JTAG-DP is as follows:

• • When the TAPSM goes through the Capture-IR state, 0b0001 is transferred onto the Instruction register (IR) scan chain. The IR scan chain is connected between JTDI and JTDO.
• • While the TAPSM is in the Shift-IR state, the IR scan chain shifts one bit for each rising edge of JTCK. This means that on the first tick:
  • – The LSB of the IR scan chain is output on JTDO.
  • – Bit[n] of the IR scan chain is transferred to bit[n-1].
  • – The value on JTDI is transferred to the MSB of the IR scan chain.
• • When the TAPSM goes through the Update-IR state, the value scanned into the IR scan chain is transferred into the Instruction register.
• • When the TAPSM goes through the Capture-DR state, a value is transferred from one

of the Data registers onto one of the DR scan chains, connected between JTDI and JTDO.

• • The value held in the Instruction register determines which Data register (and associated DR scan chain) is selected.
• • This data is then shifted while the TAPSM is in the Shift-DR state, in the same manner as the IR shift in the Shift-IR state.
• • When the TAPSM goes through the Update-DR state, the value scanned into the DR scan chain is transferred into the selected Data register.
• • When the TAPSM is in the Run-Test/Idle state, no special actions occur. The IDCODE instruction is loaded in IR.

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

The data registers corresponding to the 4-bit IR instructions are listed in Table 189 . The total IR instruction length is 9 bits.

Table 189. JTAG-DP data registers

Table 189. JTAG-DP data registers (continued)

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

32.4.2 SW debug port

The Serial Wire Debug protocol uses two pins:

• • SWCLK: clock from host to target
• • SWDIO: bi-directional serial data (100 kΩ 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, see Table 190 .
2. 2. acknowledge response (3 bits) transmitted by the target, see Table 191 .
3. 3. data transfer (33 bits) transmitted by the host (in case of a write) or target (in case of a read), see Table 192 .

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

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

Table 190. Packet request

In the case of a FAULT or WAIT ACK response from the target, the data transfer phase is canceled, unless overrun detection is enabled: in this case the data 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 in 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.

32.4.3 Debug port registers

Both the SW-DP and the JTAG-DP access the debug port (DP) registers listed in Table 193 .

The debugger can access the DP registers as follows:

• • Program the A(3:2) field in the DPACC register, if using JTAG, with the register address within the bank. Program the RnW bit to select a Read or 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 reset (see Table 190 ). The write data are sent in the data phase.
• • To access one of the banked DP registers at address 0x4, the register number must first be written to the DP_SELECT register at address 0x8. Any subsequent read or write to address 0x4 accesses the register corresponding to the content of the DP_SELECT register.

32.4.4 DP debug port identification register (DP_PIDR)

Address offset: 0x0

Reset value: 0x5BA0 2477

Read only

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

0x5

Bits 27:20 PARTNO[7:0] : Part number for the debug port

0xBA

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

Bit 16 MIN : Minimal debug port (MINDP) implementation

0x0: 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® JEDEC code

Bit 0 Reserved, must be kept at reset value.

32.4.5 DP abort register (DP_ABORTR)

Address offset: 0x0

Reset value: 0x0000 0000

Write only

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

Bit 4 ORUNERRCLR : Overrun error clear

0: No effect

1: Clear CTRL/STAT.STICKYORUN bit

Bit 3 WDERRCLR : Write data error clear

0: No effect

1: Clear CTRL/STAT.WDATAERR bit

Bit 2 STKERRCLR : Sticky error clear

0: No effect

1: Clear CTRL/STAT.STICKYERR bit

Bit 1 STKCMPCLR : Sticky compare clear

0: No effect

1: Clear CTRL/STAT.STICKYCMP bit

Bit 0 DAPABORT : Aborts current AP transaction if an excessive number of WAIT responses are returned, indicating that the transaction is stalled.

0: No effect

1: Abort transaction

32.4.6 DP control and status register (DP_CTRL/STATR)

Address offset: 0x4 and DP_SELECTR.DPBANKSEL = 0

Reset value: 0x0000 0000

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

Bit 29 CDBGPWRUPACK : See description in Section 32.3.4: DBG clocks .

0 = DAPCLK gated

1 = DAPCLK enabled

Bit 28 CDBGPWRUPREQ : Controls the DAPCLK enable request signal.

0 = Requests DAPCLK gating

1 = Requests DAPCLK enable

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

1. Bits 23:12 TRNCNT[11:0] : Transaction counter. To program a sequence of transactions to incremental addresses via an AP, TRNCNT is loaded with the number of transactions to perform. It is decremented at the successful completion of each transaction.
2. Bits 11:8 MASKLANE[3:0] : Indicates the bytes to be masked in pushed-compare and pushed-verify operations (CTRL/STAT.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.
3. • 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
4. Bit 7 WDATAERR . Write data error (read only) in SW-DP. Indicates that:
5. • – there is a parity or framing error on the data phase of a write, or
   • – a write that has been accepted by the DP is then discarded without being submitted to the AP.
6. This bit is reset by writing 1 to the ABORT.WDERRCLR bit.
7. • 0: No error
   • 1: Error has occurred
8. Reserved in JTAG-DP.
9. Bit 6 READOK . AP read response (read only) in SW-DP. Indicates the response to the last AP read access.
10. • 0: Read not OK
    • 1: Read OK
11. Reserved in JTAG-DP.
12. Bit 5 STICKYERR . Transaction error (read only in SW-DP, R/W in JTAG-DP). Indicates that an error occurred in an AP transaction.
13. • 0: No error
    • 1: Error has occurred
14. In the SW-DP, this bit is reset by writing 1 to the ABORT.STKERRCLR bit. In the JTAG-DP, this bit is reset by writing a 1 to it.
15. Bit 4 STICKYCMP . Compares match (read only in SW-DP, R/W in JTAG-DP). Indicates that a match occurred in a pushed operation.
16. • 0: Match if TRNMODE = 0x1; no match if TRNMODE = 0x2
    • 1: No match if TRNMODE = 0x1; match if TRNMODE = 0x2
17. In the SW-DP, this bit is reset by writing 1 to the ABORT.STKCMPCLR bit. In the JTAG-DP, this bit is reset by writing a 1 to it.
18. Bits 3:2 TRNMODE[1:0] : Transfer mode for AP write operations (for read operations, this field must be set to 0x0).
19. • 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 is compared with the stored data and 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 and if they match, the STICKYCMP bit is set.
    • 0x3: reserved
20. In pushed operation, only the data bytes indicated by the MASKLANE field are included in the compare.

Bit 1 STICKYORUN . Overrun (read only in SW-DP, R/W in JTAG-DP). 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.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 is blocked until the STICKYORUN bit is cleared.

32.4.7 DP data link control register (DP_DLCR)

Address offset: 0x4 and DP_SELECTR.DPBANKSEL = 1

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

Bit 7 Reserved, must be kept at reset value.

Bit 6 Reserved, must be kept at reset value (set to 1).

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

32.4.8 DP target identification register (DP_TARGETIDR)

Address offset: 0x4 and DP_SELECTR.DPBANKSEL = 2

Reset value: 0x0495 0041

Bits 31:28 TREVISION : Target revision.

0x0: revision 1

Bits 27:12 TPARTNO : Target part number.

0x4950: STM32WB50CG/30CE

Bits 11:1 TDESIGNER : Target designer JEDEC code.

0x020: STMicroelectronics

Bit 0 Reserved, must be kept at reset value (set to 1)

32.4.9 DP data link protocol identification register (DP_DLPIDR)

Address offset: 0x4 and DP_SELECTR.DPBANKSEL = 3

Reset value: 0x0000 0001

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

0x0: Instance number 0

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

Bits 3:0 PROTSVN[3:0] : Serial Wire Debug protocol version.

0x1: Version 2

32.4.10 DP resend register (DP_RESENR)

Address offset: 0x8

Reset value: 0x0000 0000

Bits 31:0 RESEND : Returns the value that was returned by the last AP read or DP RDBUFF read. Used in the event of a corrupted read transfer.

32.4.11 DP access port select register (DP_SELECTR)

Address offset: 0x8

Reset value: Unknown

Bits 31:24 APSEL[7:0] : Access port select. Selects the access port for the next transaction.

0x0: AP0 - CPU1 (Cortex®-M4) debug access port (AHB-AP)

0x1: AP1 - CPU2 (Cortex®-M0+) debug access port (AHB-AP)

0x2 to 0xFF: reserved

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

Bits 7:4 APBANKSEL[3:0] : AP register bank select. Selects the 4-word register bank on the active AP for the next transaction.

Bits 3:0 DPBANKSEL[3:0] : DP register bank select. Selects 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

32.4.12 DP read buffer register (DP_BUFFR)

Address offset: 0xC

Reset value: 0x0000 0000

Bits 31:0 RDBUFF[31:0] : Contains the value that was returned by the last AP read access. The value returned by an AP read access can either be obtained using a second read access to the same address, which initiates a new transaction on the corresponding bus, or else it can be read from this register, in which case no new AP transaction occurs.

32.4.13 DP target selection register (DP_TARGETSELR)

Address offset: 0xC

Reset value: Unknown

Bits 31:28 TINSTANCE[3:0] : Target instance number. Defines the instance number for the target device in a multi-drop system. These bits must be written with the same value used for DLPIDR.TINSTANCE to select this device.

Bits 27:12 TPARTNO[15:0] : Target part number. Defines the part number for the target device. These bits must be written with the same value used for TARGETID.TPARTNO to select this device.

Bits 11:1 TDESIGNER[10:0] : Target designer JEDEC code. Defines the JEDEC code for the target device. These bits must be written with the same value used for TARGETID.TDESIGNER to select this device.

Bit 0 Reserved, must be kept at reset value (set to 1).

32.4.14 Debug port register map and reset values

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

The debug port address is 2-bit wide, defined in the JTAG-DP register DPACC or SW-DP packet request A[3:2] field.

Table 193. Debug port register map and reset values

1. 1. DP_SELECTR.DPBANKSEL = 1.
2. 2. DP_SELECTR.DPBANKSEL = 2.
3. 3. DP_SELECTR.DPBANKSEL = 3.

32.5 Access ports

As shown in Figure 346 , there are two access ports (AP) attached to the DP:

1. 1. AP0: CPU1 (Cortex ^® -M4) access port (AHB-AP): enables access to the debug and trace features integrated in the Cortex ^® -M4 processor core via its internal AHB bus.
2. 2. AP1: CPU2 (Cortex ^® -M0+) access port (AHB-AP): enables access to the debug and trace features integrated in the Cortex ^® -M0+ processor core via its internal AHB bus.

Both access ports are of type MEM-AP, 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 194 .

Figure 346. 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)]
    AP0 <--> CPU1[CPU1 Cortex®-M4]
    AP1 <--> CPU2[CPU2 Cortex®-M0+]
  

The address of the AP registers is composed of

• • Bits [7:4]: content of the SELECT register APBANKSEL field in the DP (see Section 32.4.11 )
• • Bits [3:2]: content of the A(3:2) field of the APACC data register in the JTAG-DP (see Table 193 ) or of the SW-DP Packet Request (see Table 190 ), 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 SELECT register APSEL field in the DP to choose one of the APs, and the APBANKSEL field to select the register bank to be accessed (see Section 32.4.11 ).
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 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 190 ). The write data is sent in the data phase.

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

1. 1. Program the transaction target address in the TAR register.
2. 2. Program the CSW register, if necessary, with the transfer parameters (AddrInc for example).
3. 3. Write to or read from the DRW register to initiate a bus transaction at the address held in the TAR register. Alternatively, a read or write to Banked data register BDN triggers an access to address \( TAR[31:4] + n \) (this enables up to four consecutive addresses to be accessed 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].

32.5.1 AP control/status word register (AP_CSWR)

Address offset: 0x0

Reset value: 0x2300 0040

Bit 31 Reserved, must be kept at reset value.

Bit 30 SPROT : Secure transfer request. 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. 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 SPSTATUS : Status of SPIDEN option bit (read only). This signal determines whether the debugger can access secure memory.

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. Defines if memory barrier operation is supported.

0x0: Not supported

Bit 7 TRINPROG : Transfer in progress (read only). Indicates if a bus transfer is in progress on the AP.

0x0: No transfer in progress.

0x1: Bus transfer in progress.

Bit 6 DEVICEEN : Device enabled (read only). Defines whether the AP can be accessed.

0x1: AP access enabled.

Bits 5:4 ADDRINC[1:0] : Auto-increment mode. Defines whether 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. A 32-bit AP access gives rise to 1 x 32-bit, 2 x 16-bit, or 4 x 8-bit bus transactions, corresponding to the programmed transaction size. Data are packed or unpacked accordingly.

0x3: reserved

Bit 3 Reserved, must be kept at reset value.

Bits 2:0 SIZE[2:0] : Size of next memory access transaction

0x0: Byte (8-bit)

0x1: Halfword (16-bit)

0x2: Word (32-bit)

0x3-0x7: reserved

32.5.2 AP transfer address register (AP_TAR)

Address offset: 0x04

Reset value: 0x0000 0000

Bits 31:0 TA[31:0] : Address of current transfer

32.5.3 AP data read/write register (AP_DRWR)

Address offset: 0x0C

Reset value: 0x0000 0000

Bits 31:0 TD[31:0] : Data of current transfer

32.5.4 AP banked data registers (AP_BD0-3R)

Address offset: 0x10 (DB0R)

Address offset: 0x14 (BD1R)

Address offset: 0x18 (BD2R)

Address offset: 0x1C (BD3R)

Reset value: 0x0000 0000

Bits 31:0 TBD[31:0] : Banked data of current transfer to address TAR. TA+ AP_BDnR address [3:2] + 0b00. Auto address incrementing is not performed on AP_BD0-3R. Banked transfers are only supported for word transfers.

32.5.5 AP base address register (AP_BASER)

Address offset: 0xF8

Reset value: 0xE00F F003 (AP0), 0xF000 0003 (AP1)

Bits 31:12 BASEADDR[19:0] : Base address (bits 31 to 12) of ROM table for the AP. The twelve LSBs are 0 since the ROM table must be aligned on a 4-Kbyte boundary.

AP0 CPU1 (Cortex®-M4) AHB-AP: 0xE00FF

AP1 CPU2 (Cortex®-M0+) AHB-AP: 0xF0000

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 : Indicates that debug components are present on the access port bus.

1: Debug components are present

32.5.6 AP identification register (AP_IDR)

Address offset: 0xFC

Reset value: 0x2477 0011 (AP0), 0x6477 0001 (AP1)

Read only

0x2: r0p3

0x6: r0p7

0x1: Standard register map

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

32.5.7 Access port register map and reset values

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

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

Table 194. Access port register map and reset values

32.6 Cross trigger interface (CTI) and matrix (CTM)

The Cross trigger interfaces (CTIs) and Cross trigger matrix (CTM), taken together, form the CoreSight™ embedded cross trigger (see Figure 347).

There are two CTI components, one dedicated to the CPU2 and one dedicated to the CPU1. The CTIs are connected to each other via the CTM. The CTI registers are accessible to the debugger via the corresponding access port and associated AHB.

The CTIs enable 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 eight trigger inputs and eight trigger outputs. Any input can be connected to any output, on the same CTI, or on another CTI via the CTM.

The trigger input and output signals for each CTI are listed in tables 195 to 198.

Table 195. CPU2 CTI inputs

Table 196. CPU2 CTI outputs

Table 197. CPU1 CTI inputs

Table 198. CPU1 CTI outputs

There are four event channels in the cross trigger matrix, thus enabling 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 348. Mapping 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 one of them stops the HALTED output of each core must be connected to the EDBGREQ input of the opposite core.

Referring to Table 195 and Table 197 , we see that the HALTED signal from the CPU2 is connected to input 0 of the CPU2 CTI, and the same signal from the CPU1 is connected to the same input on the CPU1 CTI. Hence we program the CTIINEN0 register on each CTI to connect these inputs to a CTM channel (eg. channel 0).

From Table 196 and Table 198 we see that the EDBGREQ signals to the CPUs are connected to output 0 of the respective CTIs. So we program the CTIOUTEN0 register on each CTI to connect these outputs to the same CTM channel.

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

From Table 196 and Table 198 we see that the DBGRESTART signals to the CPUs are connected to output 1 of the respective CTIs. So we program the CTIOUTEN1 register on each CTI, to connect these outputs to an unused CTM channel (e.g. channel 1).

The above configuration is illustrated in Figure 349 .

Figure 349. Cross trigger configuration example

To force the processors to restart simultaneously, 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 generates 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].

32.7 Cross trigger interface registers

The register file base address is 0xE0043000 for CPU1 CTI and 0xF0001000 for CPU2 CTI. CPU1 CTI and CPU2 CTI are accessed via different access ports. The registers are the same for each CTI.

32.7.1 CTI control register (CTI_CONTROLR)

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

32.7.2 CTI trigger acknowledge register (CTI_INTACKR)

Address offset: 0x010

Reset value: 0x0000 0000

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

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

32.7.3 CTI application trigger set register (CTI_APPSETR)

Address offset: 0x014

Reset value: 0x0000 0000

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

Bit 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

32.7.4 CTI application trigger clear register (CTI_APPCLEAR)

Address offset: 0x018

Reset value: 0x0000 0000

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

Bit 3:0 APPCLEAR[3:0] : Clear channel event.

• 0b0000: No effect
• 0bXXX1: Clear event on Channel 0
• 0bXX1X: Clear event on Channel 1
• 0bX1XX: Clear event on Channel 2
• 0b1XXX: Clear event on Channel 3

32.7.5 CTI application pulse register (CTI_APPPULSER)

Address offset: 0x01C

Reset value: 0x0000 0000

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

Bit 3:0 APPPULSE[3:0] : Pulse channel event. This register clears itself immediately.

• 0b0000: No effect
• 0bXXX1: Generate pulse on Channel 0
• 0bXX1X: Generate pulse on Channel 1
• 0bX1XX: Generate pulse on Channel 2
• 0b1XXX: Generate pulse on Channel 3

32.7.6 CTI trigger In x enable register (CTI_INENRx)

Address offset: 0x020 + 4 * x, where x = 0 to 7

Reset value: 0x0000 0000

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

Bit 3:0 TRIGINEN[3:0] : Enables or disables a cross trigger event on each of the four channels when CTITRIGINx is activated (x = 0 to 7).

0b0000: Trigger does not generate events on Channels
0bXXX1: Trigger n generates events on Channel 0
0bXX1X: Trigger n generates events on Channel 1
0bX1XX: Trigger n generates events on Channel 2
0b1XXX: Trigger n generates events on Channel 3

32.7.7 CTI trigger out x enable register (CTI_OUTENRx)

Address offset: 0x0A0 + 4 * x, where x = 0 to 7

Reset value: 0x0000 0000

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

Bit 3:0 TRIGOUTEN[3:0] : For each channel, defines whether an event on that channel generates a trigger on CTITRIGOUTx (x = 0 to 7).

0b0000: Channel events do not generate triggers on Trigger outputs
0bXXX1: Channel 0 events generate triggers on Trigger output n
0bXX1X: Channel 1 events generate triggers on Trigger output n
0bX1XX: Channel 2 events generate triggers on Trigger output n
0b1XXX: Channel 3 events generate triggers on Trigger output n

32.7.8 CTI trigger in status register (CTI_TRGISTSR)

Address offset: 0x130

Reset value: 0x0000 0000

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

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

32.7.9 CTI trigger out status register (CTI_TRGOSTSR)

Address offset: 0x134

Reset value: 0x0000 0000

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

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

32.7.10 CTI channel in status register (CTI_CHINSTSR)

Address offset: 0x138

Reset value: 0x0000 0000

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

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

32.7.11 CTI channel out status register (CTI_CHOUTSTSR)

Address offset: 0x13C

Reset value: 0x0000 0000

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

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

32.7.12 CTI channel gate register (CTI_GATER)

Address offset: 0x140

Reset value: 0x0000 000F

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

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

0b0000: Channels events do not propagate

0bXXX1: Channel 0 events propagate

0bXX1X: Channel 1 events propagate

0bX1XX: Channel 2 events propagate

0b1XXX: Channel 3 events propagate

32.7.13 CTI claim tag set register (CTI_CLAIMSETR)

Address offset: 0xFA0

Reset value: 0x0000 000F

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

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

Write:

• 0000: No effect
• xxx1: Set bit 0
• xx1x: Set bit 1
• x1xx: Set bit 2
• 1xxx: Set bit 3

Read:

0xF: Indicates there are four bits in claim tag

32.7.14 CTI claim tag clear register (CTI_CLAIMCLR)

Address offset: 0xFA4

Reset value: 0x0000 0000

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

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

Write:

• 0000: No effect
• xxx1: Clear bit 0
• xx1x: Clear bit 1
• x1xx: Clear bit 2
• 1xxx: Clear bit 3

Read: Returns current value of claim tag

32.7.15 CTI lock access register (CTI_LAR)

Address offset: 0xFB0

Reset value: N/A

Bits 31:0 ACCESS_W[31:0] : Enables write access to some CTI registers by processor cores (debuggers do not need to unlock the component)

0xC5AC CE55: Write access enabled

Other values: Write access disabled

32.7.16 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 : Indicates the size of the CTI_LAR register

0: 32-bit

Bit 1 LOCKGRANT : Current status of lock. This bit always reads as zero by an external debugger.

0: Write access is permitted

1: Write access is blocked. Only reads are permitted.

Bit 0 LOCKEXIST : Indicates whether a lock control mechanism exists. This bit always reads as zero by an external debugger.

0: No lock control mechanism exists.

1: Lock control mechanism is implemented

32.7.17 CTI authentication status register (CTI_AUTHSTATR)

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

32.7.18 CTI device configuration register (CTI_DEVIDR)

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

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

32.7.20 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 KB region

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

0x4: Arm® JEDEC code

32.7.21 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 bits [7:0]

0x06: CTI part number

32.7.22 CTI CoreSight peripheral identity register 1 (CTI_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 00B9

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

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

0xB: Arm® JEDEC code

Bits 3:0 PARTNUM[11:8] : Part number bits [11:8]

0x9: CTI part number

32.7.23 CTI CoreSight peripheral identity register 2 (CTI_PIDR2)

Address offset: 0xFE8

Reset value: 0x0000 004B

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

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

0x4: r0p5

Bit 3 JEDEC : JEDEC assigned value

0x1: Designer ID specified by JEDEC

Bits 2:0 JEP106ID[6:4] : JEP106 identity code bits [6:4]

0x3: Arm® JEDEC code

32.7.24 CTI CoreSight peripheral identity register 3 (CTI_PIDR3)

Address offset: 0xFEC

Reset value: 0x0000 0000

Bit 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

32.7.25 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 bits [7:0]

0x0D: Common ID value

32.7.26 CTI CoreSight peripheral identity register 1 (CTI_CIDR1)

Address offset: 0xFF4

Reset value: 0x0000 0090

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

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

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

32.7.27 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 bits [23:16]
0x05: Common ID value

32.7.28 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 bits [31:24]
0xB1: Common ID value

32.7.29 CTI register map and reset values

Table 199. CTI register map and reset values

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

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