59. Debug support (DBG)

59.1 DBG introduction

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

• • Breakpoint debugging of the CPU core
• • 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.

• – SWJ-DP: JTAG/Serial-wire debug port
• – AHB-AP: AHB access port
• – ROM table
• – System control space (SCS)
• – Breakpoint unit (BPU)
• – Data watchpoint and trace unit (DWT)
• – Instrumentation trace macrocell (ITM)
• – Embedded Trace Macrocell ^™ (ETM)
• – Cross-trigger interface (CTI)
• – Trace port interface unit (TPU)

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

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

59.2 DBG functional description

59.2.1 DBG block diagram

Figure 850. Block diagram of debug support infrastructure

59.2.2 DBG pins and internal signals

Table 709. JTAG/Serial-wire debug port pins

1. TDI is hosted on the same I/O as a USBBPD-CC line. To avoid pull-up/down conflict, a user option can help to decide whether the pad is used as TDI or as CC.

Table 710. Trace port pins

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

59.2.3 DBG reset and clocks

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

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 modes, as well as to operate the state machines and internal logic of the debug port. This clock 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 DCLK domain that covers the rest of the SWJ-DP and the access port.

The DCLK is a gated version of the system clock.

The DCLK domain is enabled by the debugger using the CDBGPWRUPREQ bit in the DP control and status register (DP_CTRLSTATR) . 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 DP_CTRL/STATR. The DCLK is disabled at power-up, and must be disabled when the debugger is disconnected, to avoid wasting energy.

The debug and trace components included in the processor are clocked with the processor clock.

59.2.4 DBG power domains

The debug components are located in the core power domain. This means that the debugger connection is not possible in Shutdown or Standby low-power mode. To avoid losing the connection when the device enters Standby mode, the power can be maintained to the core by setting a bit in the DBGMCU configuration register (DBGMCU_CR) . This also keeps the processor clocks active and holds off the reset, so that the debug session is maintained.

59.2.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 if the core is not clocked, all debug components 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, but the debugger does not lose the connection.

The emulation mode is programmed in the microcontroller debug (DBGMCU) unit. For more information, refer to Section 59.12 .

59.2.6 Security

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

Debugger access to secure memory (when permitted) must be performed using secure transactions on the debug AHB, that is, with the PROT[6] bit set in the AP1 control/status word register (AP1_CSWR) .

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

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

• • dbgen : global enable for all debug features
  • 0: All debug features are disabled.
  • 1: Debug features in the nonsecure state are enabled. Debug features in the secure state are dependent on the state of the spiden signal.
• • spiden : enables debug in the secure state when dbgen = 1.
  • 0: Debug features are disabled in the secure state.
  • 1: Debug features are enabled in the secure state.
• • niden : enables trace and performance monitoring (noninvasive debug).
  • 0: Trace generation is disabled.
  • 1: Trace generation in the nonsecure state is enabled. Trace generation in the secure state is dependent on the state of the spniden signal.
• • spniden : enables trace and performance monitoring in the secure state when niden = 1.
  • 0: Trace generation is disabled in the secure state.
  • 1: Trace generation is enabled in the secure state.

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

The state of the signals is set according to the debug state as shown in Table 712 , when TrustZone® is enabled (TZEN = 0xB4), and Table 713 when TrustZone is disabled (TZEN = 0xC3).

Table 712. Authentication signal states with TrustZone enabled (TZEN = 0xB4)

Table 713. Authentication signal states with TrustZone disabled (TZEN = 0xC3)

The state of the authentication signals can be read from the DAUTHSTATUS register in the system control space (SCS) of the Cortex®-M33.

The debug state depends upon the product life cycle state and the debug authentication state (see Section 59.2.7 ).

Table 714. Life cycle state and debug states

Table 714. Life cycle state and debug states

1. Depends on authorization level.

59.2.7 Debug authentication

Figure 851. Product life cycle states and debug authentication

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

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

Reopening the debug is possible only if sensitive asset security is ensured (and TrustZone is enabled (TZEN = 0xB4). This is called Constrained Debug, as constraints ensure the security of the ROT information.

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

• • Partial regression corresponds to releasing nonsecure code and assets. The intermediate state which allows partial regression management is called NS-Regression.
• • Full regression corresponds to releasing all code and assets. The intermediate state allowing full regression management is called Regression.

Debug authentication control principle

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

To control the reopening of the debug, the device imposes a debug authentication protocol.

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

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

The host can write to the mailbox via the JTAG/SWD interface. It expects to get responses and messages from the device via the same mailbox.

The debug authentication protocol is launched on a power-on reset of the device, when an “open request” message is posted by the host.

The protocol is based on:

• • Initial message: posted by the host combined with a reset to launch the debug authentication process on the device.
• • Challenge message: the device generates a random value, to be signed by the host, when sending back the response.
• • Response: the host sends a message to the device proving its authenticity. This is done using a tool to generate a token.

The implementation is ensured by code embedded in the system flash. This code is called automatically after reset if an initial message has been posted by the host in the mailbox.

After a first sequence of mutual authentication to align on protocol version, type of device, and similar parameters, the device generates a random value that to be signed by the host with a private key when building the response.

The STMicroelectronics implementation is based on the Arm® PSA-ADAC solution for debug authentication.

The debug authentication can be implemented using a proprietary or open-source protocol.

As this feature is critical for security, the STM32H5 devices come with debug authentication provisioned in system flash. STMicroelectronics provides the host tools integrated with some debug environments (IDEs).

Debug authentication provisioning

Debug authentication is natively supported by the STM32H5 platform. The data used by ST debug authentication (ST-DA) must be provisioned at a defined location in the secure key storage area (OBKeys defined in flash memory).

The debug authentication configuration must be done only when the PRODUCT_STATE is “Provisioning”, cannot be performed when PRODUCT_STATE is “Open”.

The following data must be provisioned (refer to Section 7.7.2: RSS user functions ):

• • Data must be provisioned at the very beginning of the OBK_HDPL1 mapping (0x0FFD 0100) (see Section 7.5.2: OBK access per HDPL level )
• • RSS_Lib encryption option must be set for STM32H533/573xx devices
• • RSS_Lib encryption option must be reset for STM32H523/56xxx devices

The data to provision are defined in Table 715 . They depend upon the TZEN option byte setting (enabled or disabled).

Table 715. Definition of data to provision

Caution: Configure debug authentication as explained above before changing to states different from Open or Provisioning.

Table 716. Permission mask (Endianness: Little Endian)

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

These two modes are mutually exclusive, since they share the same I/O pins.

By default, the JTAG-DP is selected after a system or a power-on reset. The five I/O 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.

Note: All SWJ port I/Os can be reconfigured to other functions by software, but debugging is no longer possible.

59.3.1 JTAG debug port

The JTAG-DP implements a TAP state machine (TAPSM), shown in the figure below, 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 852. 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-IR-Scan --> Capture-IR: JTMS=0
    Capture-DR --> Shift-DR: JTMS=0
    Capture-IR --> Shift-IR: JTMS=0
    Shift-DR --> Shift-DR: JTMS=0
    Shift-DR --> Exit1-DR: JTMS=1
    Shift-IR --> Shift-IR: JTMS=0
    Shift-IR --> Exit1-IR: JTMS=1
    Exit1-DR --> Pause-DR: JTMS=0
    Exit1-IR --> Pause-IR: JTMS=0
    Pause-DR --> Pause-DR: JTMS=0
    Pause-DR --> Exit2-DR: JTMS=1
    Pause-IR --> Pause-IR: JTMS=0
    Pause-IR --> Exit2-IR: JTMS=1
    Exit2-DR --> Update-DR: JTMS=1
    Exit2-IR --> Update-IR: JTMS=1
    Update-DR --> Run-Test/Idle: JTMS=0
    Update-DR --> Select-DR-Scan: JTMS=1
    Update-IR --> Run-Test/Idle: JTMS=0
    Update-IR --> Select-IR-Scan: JTMS=1

MSv67392V1

The operation of the JTAG-DP is as follows:

1. 1. 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.
2. 2. 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.
3. 3. When the TAPSM goes through the Update-IR state, the value scanned into the IR scan chain is transferred to the instruction register.
4. 4. When the TAPSM goes through the Capture-DR state, a value is transferred from one of the data registers to one of the DR scan chains, connected between JTDI and JTDO.
5. 5. The value held in the instruction register determines which data register, and associated DR scan chain, are selected.
6. 6. This data is then shifted while the TAPSM is in the Shift-DR state, in the same manner as the IR shifts in the Shift-IR state.
7. 7. When the TAPSM goes through the Update-DR state, the value scanned into the DR scan chain is transferred to the selected data register.
8. 8. When the TAPSM is in the Run-Test/Idle state, no special actions occur. The IDCODE instruction is loaded in IR.

When active, the nJTRST signal resets the state machine asynchronously to the test-logic-reset state.

The data registers corresponding to the 4-bit IR instructions are listed in the table below.

Table 717. JTAG-DP data registers

Table 717. JTAG-DP data registers (continued)

The DR registers are described in more detail in the Arm ^® Debug Interface Architecture Specification (see Section 59.13 ).

59.3.2 Serial-wire debug port

The serial-wire debug protocol uses the following pins:

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

Serial data is transferred LSB first, synchronously with the clock.

A transfer comprises three phases:

1. 1. Packet request (8 bits) transmitted by the host, see Table 718
2. 2. Acknowledge response (3 bits) transmitted by the target, see Table 719
3. 3. Data transfer (33 bits) transmitted by the host (in case of a write) or target (in case of a read), see Table 720

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

Table 719. ACK response

Table 720. Data transfer

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

59.3.3 Debug port registers

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

The debugger can access the DP registers as follows:

1. 1. 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 718 ). The write data are sent in the data phase.
2. 2. To access one of the banked DP registers at the address 0x4, the register number must first be written to the DP_SELECTR register at the address 0x8. Any subsequent read or write to address 0x4 accesses the register corresponding to the contents of the DP_SELECTR register.

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

DP debug port identification register (DP_PIDR)

Address offset: 0x0

Reset value: 0x6BA0 2477

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

0x6: Rev 6

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

Bits 15:12 VERSION[3:0] : debug port 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.

DP abort register (DP_ABORTR)

Address offset: 0x0

Reset value: 0x0000 0000

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

Bit 4 ORUNERRCLR : overrun error clear

0: no effect

1: STICKYORUN bit cleared in DP_CTRL/STATR register

Bit 3 WDERRCLR : write data error clear

0: no effect

1: WDATAERR bit cleared in DP_CTRL/STATR register

Bit 2 STKERRCLR : sticky error clear

0: no effect

1: STICKYERR bit cleared in DP_CTRL/STATR register

Bit 1 Reserved, must be kept at reset value.

Bit 0 DAPABORT : current AP transaction aborted if excessive number of WAIT responses returned

This bit indicates that the transaction is stalled.

0: no effect

1: transaction aborted

DP control and status register (DP_CTRLSTATR)

Address offset: 0x4

Reset value: 0x0000 0000

This register is accessible when DP_SELECTR.DPBANKSEL[3:0] = 0x0.

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

Bit 29 CDBGPWRUPACK : debug power-up acknowledge

See description in Section 59.2.5: Debug and low-power modes .

0: DCLK gated

1: DCLK enabled

Bit 28 CDBGPWRUPREQ : debug power-up request

This bit controls the DCLK enable request signal.

0: requests DCLK gating

1: requests DCLK enable

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

Bit 7 WDATAERR : write data error (read-only) in SW-DP

This bit indicates that there is a parity or framing error on the data phase of a write, or a write accepted by the DP is then discarded without being submitted to the AP.

This bit is reset by writing 1 to the ABORT.WDERRCLR bit.

0: no error

1: an error occurred

Note: This bit is reserved in JTAG-DP.

Bit 6 READOK : AP read response (read-only) in SW-DP

This bit indicates the response to the last AP read access.

0: read not OK

1: read OK

Note: This bit is reserved in JTAG-DP.

Bit 5 STICKYERR : transaction error (read-only in SW-DP, read/write in JTAG-DP)

This bit indicates that an error occurred in an AP transaction. It is reset by writing 1 to the DP_ABORTR.STKERRCLR bit (in SW-DP and JTAG-DP)

0: no error

1: an error occurred

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

Bit 1 STICKYORUN : overrun (read-only in SW-DP, read/write 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. It is reset by writing 1 to the DP_ABORTR.ORUNERRCLR bit (in SW-DP and JTAG-DP).

0: no overrun

1: an overrun occurred

Bit 0 ORUNDETECT : overrun detection mode enable.

0: disabled

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

DP data link control register (DP_DLCR)

Address offset: 0x4

Reset value: 0x0000 0000

This register is accessible when DP_SELECTR.DPBANKSEL[3:0] = 0x1 .

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

Bits 7:6 WIREMODE[1:0] : SW-DP mode

0x0: synchronous mode

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

DP target identification register (DP_TARGETIDR)

Address offset: 0x4

Reset value: 0xXXXX 0041

This register is accessible when DP_SELECTR.DPBANKSEL[3:0] = 0x2.

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

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

0x4840: STM32H562/563/573

0x4780: STM32H523/533

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

0x020: STMicroelectronics

Bit 0 Reserved, must be kept at reset value.

DP data link protocol identification register (DP_DLPIDR)

Address offset: 0x4

Reset value: 0x0000 0001

This register is accessible when DP_SELECTR.DPBANKSEL[3:0] = 0x3.

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

this field defines the instance number for the 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

DP event status register (DP_RESENR)

Address offset: 0x8

Reset value: 0x0000 0000

Bits 31:0 RESEND[31:0] : value returned by the last AP read or DP_RDBUFF read

This register is used in the event of a corrupted read transfer.

DP access port select register (DP_SELECTR)

Address offset: 0x8

Reset value: 0xXXXX XXXX

Bits 31:24 APSEL[7:0] : access port select

This field selects the access port for the next transaction.

0x00: AP0 - System debug access port (APB-AP)

0x01: AP1 - Cortex ^® -M33 debug access port (AHB-AP)

Others: reserved

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

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

This field selects the 4-word register bank on the active AP for the next transaction.

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

This field selects the register at the address 0x4 of the debug port.

• 0x0: DP_CTRLSTAT register
• 0x1: DP_DLCR register
• 0x2: DP_TARGETID register
• 0x3: DP_DPIDR register
• Others: reserved

DP read buffer register (DP_RDBUFR)

Address offset: 0xC

Reset value: 0x0000 0000

Bits 31:0 RDBUFF[31:0] : value returned by the last AP read access

The value returned by an AP read access can be obtained using a second read access to the same address (initiates a new transaction on the corresponding bus), or can be read from this register, in which case no new AP transaction occurs.

59.3.4 Debug port register map and reset values

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

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

Table 722. Debug port register map and reset values

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

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

59.4 Access ports

There are two access ports (AP) attached to the DP.

• • System debug access port (AP0): Enables access to the DBGMCU and the system ROM table via an APB bus.
• • Cortex ^® -M33 debug access port (AP1): Enables access to the debug and trace features integrated in the Cortex ^® -M33 processor core via its internal AHB bus.

59.4.1 Access port registers

The access ports are of type MEM-AP: the debug and trace component registers are mapped in the address space of the AHB. 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 724 .

The address of the AP registers is composed of the following fields:

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

The content of the DP_SELECTR.APSEL[3:0] field defines which MEM-AP is being accessed.

Table 723. MEM-AP registers

Table 723. MEM-AP registers (continued)

The debugger can access the AP registers as follows:

1. 1. Program the APSEL[3:0] field in the DP access port select register (DP_SELECTR) to choose the AP, and the APBANKSEL[3:0] field in DP_SELECTR to select the register bank to be accessed.
2. 2. Program the A(3:2) field in the APACC data 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 718 ). The write data is sent in the data phase.

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

1. 1. Program the transaction target address in the APx transfer address register (APx_TAR) ( \( x = 0, 1 \) ).
2. 2. Program the AP1 control/status word register (AP1_CSWR) , if necessary, with the transfer parameters (AddrInc for example).
3. 3. Write to or read from the APx data read/write register (APx_DRWR) ( \( x = 0, 1 \) ) to initiate a bus transaction at the address held in AP_TAR. Alternatively, a read or write to the APx banked data n register (APx_BDnR) ( \( x = 0, 1 \) ) triggers access to the TAR[31:4] + n address, allowing up to four consecutive addresses to be accessed without changing the address in the AP_TAR register.

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

AP0 control/status word register (AP0_CSWR)

Address offset: 0x0

Reset value: 0x8000 0042

Bit 31 DBGSWEN : software access enable

Enables or disables software access to the APB bus

0: disable software access

1: enable software access

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

Bits 11:8 MODE[3:0] : mode of operation

0b0000: normal download or upload

other: reserved

Bit 7 TRINPROG : transfer in progress (read only)

This field indicates whether a transfer is currently in progress on the APB master port

0: no APB transfer in progress

1: APB transfer in progress

Bit 6 DEVICEEN : device enable status (read only)

1: APB transfers always 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 incremented by the size in bytes of the transaction (SIZE field)

other: reserved

Bit 3 Reserved, must be kept at reset value.

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

0x2: word (32-bit)

AP1 control/status word register (AP1_CSWR)

Address offset: 0x0

Reset value: 0x43X0 00X2

Bit 31 Reserved, must be kept at reset value.

Bit 30 SPROT : secure transfer request

This field sets the protection attribute HPROT[6] of the bus transfer.

0: secure transfer, HPROT[6] = low

1: nonsecure transfer, HPROT[6] = high

If SPIDEN = 0 and SPROT = 0, no bus transfer occurs

Bits 29:28 Reserved, must be kept at reset value.

Bits 27:24 PROT[3:0] : bus transfer protection

This field sets the protection attributes HPROT[3:0] of the bus transfer.

0bXXX0: instruction access

0bXXX1: data access

0bXX0X: user mode

0bXX1X: privilege mode

0bX0XX: non-bufferable

0bX1XX: bufferable

0b0XXX: non-shareable, no look-up, non-modifiable

0b1XXX: shareable, look-up, modifiable

Bit 23 SPISTATUS : secure debug authentication status

This field indicates the state of the SPIDEN signal

0: No secure AHB transfers allowed

1: Secure AHB transfers allowed

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

Bit 7 TRINPROG : transfer in progress (read only)

This field indicates whether a transfer is currently in progress on the APB master port

0: No AHB transfer in progress

1: AHB transfer in progress

Bit 6 DBGSTATUS : debug enable (DBGEN) status

0: AHB transfers blocked

1: AHB transfers 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 incremented by the size of the transaction (SIZE field), in bytes. Single transfer.

0x2: address incremented by the size of the transaction (SIZE field), in bytes. Packs four 8-bit or two 16-bit transfers into a 32-bit DAP transfer. Multiple transactions are carried out on the AHB interface.

Others: 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)

Others: reserved

APx transfer address register (APx_TAR) (x = 0, 1)

Address offset: 0x04

Reset value: 0xXXXX XXXX

Bits 31:0 TA[31:0] : address of current transfer. In AP0, TA[1:0] are fixed at 0.

APx data read/write register (APx_DRWR) (x = 0, 1)

Address offset: 0x0C

Reset value: 0xXXXX XXXX

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

APx banked data n register (APx_BDnR) (x = 0, 1)

Address offset: 0x10 + 0x4 * n, (n = 0 to 3)

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : banked data of current transfer to address TA [31:4] + 4 * n.

Auto address incrementing is not performed on APx_BD0-3R. Banked transfers are only supported for word transfers.

APx base address register (APx_BASER) (x = 0, 1)

Address offset: 0xF8

Reset value: AP 0: 0xE00E 0003

Reset value: AP 1: 0xE00F E003

Bits 31:12 BASEADDR[31:12] : base address (bits 31 to 12) of the first ROM table

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

0xE00E0: AP0

0xE00FE: AP1

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 components presence

Indicates that debug components are present on the access port bus.

1: debug components present

APx identification register (APx_IDR) (x = 0, 1)

Address offset: 0xFC

Reset value: AP 0: 0x5477 0002

Reset value: AP 1: 0x8477 0001

Bits 31:28 REVISION[3:0] : revision number

0x5: r1p0

0x8: r0p9

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

0x4: Arm®

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

0x3B: Arm®

Bits 16:13 CLASS[3:0] :
0x1: MEM-AP

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

Bits 7:0 IDENTITY[7:0] :
0x1: AHB-AP
0x2: APB-AP

59.4.2 Access port register map

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

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

Table 724. Access port register map and reset values

Table 724. Access port register map and reset values (continued)

59.5 ROM tables

The ROM table is a CoreSight component that contains the base addresses of the CoreSight debug components accessible via the access port to which it is attached. These tables allow a debugger to discover the topology of the CoreSight system automatically.

There is one top-level ROM table behind each access port, APn. The base address of this ROM table can be obtained by reading the APn_BASER register of the access port. The top-level ROM table may point in turn to other ROM tables.

The system ROM table is pointed to by the AP0 base register, AP0_BASER. It contains the base address pointer for the DBGMCU.

The system ROM table occupies a 4-Kbyte, 32-bit wide chunk of address space, from 0xE00E 4000 to 0xE00E 4FFC, when accessed by the debugger. It can be accessed by the CPU at the address range 0x4402 4000 to 0x4402 4FFC.

Table 725. System ROM table

There are two ROM tables in the CPU subsystem. The MCU ROM table is pointed to by the AP1 base register, AP1_BASER. It contains the base-address pointer for the processor ROM table and for the TPIU registers.

The MCU ROM table (see the table below) occupies a 4-Kbyte, 32-bit wide chunk of address space, from 0xE00F E000 to 0xE00F EFFC.

Table 726. MCU ROM table

The processor ROM table contains the base-address pointer for the system control space (SCS) registers, that allow the debugger to identify the CPU core, as well as for the BPU, DWT, ITM, ETM, and CTI.

The processor ROM table (see Table 727 ) occupies a 4-Kbyte, 32-bit wide chunk of address space, from 0xE00F F000 to 0xE00F FFFC.

Table 727. Processor ROM table

Figure 853. CoreSight topology

MSv67393V1

59.5.1 System ROM table registers

System ROM memory type register (SYSROM_MEMTYPER)

Address offset: 0xFCC

Reset value: 0x0000 0001

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

Bit 0 SYSTEM : system memory

0x1: system memory present on this bus

System ROM CoreSight peripheral identity register 4 (SYSROM_PIDR4)

Address offset: 0xFD0

Reset value: 0x0000 0000

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

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

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

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

0x0: STMicroelectronics JEDEC continuation code

System ROM CoreSight peripheral identity register 0 (SYSROM_PIDR0)

Address offset: 0xFE0

Reset value: 0x0000 00XX

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

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

0x84: STM32H562/563/573

0x78: STM32H523/533

System ROM CoreSight peripheral identity register 1 (SYSROM_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 000X

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

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

0x0: STMicroelectronics JEDEC code

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

0x4: STM32H5 series

System ROM 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] : component revision number

0x0: rev r0p0

Bit 3 JEDEC : JEDEC assigned value

1: designer identification specified by JEDEC

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

0x2: STMicroelectronics JEDEC code

System ROM 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

System ROM 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 identification bits [7:0]

0x0D: Common identification value

System ROM CoreSight peripheral 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 identification bits [15:12] - component class

0x1: ROM table component

Bits 3:0 PREAMBLE[11:8] : Component identification bits [11:8]

0x0: Common identification value

System ROM 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 identification bits [23:16]

0x05: common identification value

System ROM 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 identification bits [31:24]

0xB1: Common identification value

59.5.2 System ROM table register map

Table 728. System ROM table register map and reset values

Refer to Table 725 for register boundary addresses.

59.5.3 MCU ROM table registers

MCU ROM memory type register (MCUROM_MEMTYPER)

Address offset: 0xFCC

Reset value: 0x0000 0001

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

Bit 0 SYSTEM : system memory

0x1: system memory present on this bus

MCU ROM CoreSight peripheral identity register 4 (MCUROM_PIDR4)

Address offset: 0xFD0

Reset value: 0x0000 0000

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

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

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

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

0x0: STMicroelectronics JEDEC continuation code

MCU ROM CoreSight peripheral identity register 0 (MCUROM_PIDR0)

Address offset: 0xFE0

Reset value: 0x0000 00XX

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

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

0x84: STM32H562/563/573

0x78: STM32H523/533

MCU ROM CoreSight peripheral identity register 1 (MCUROM_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 000X

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

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

0x0: STMicroelectronics JEDEC code

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

0x4: STM32H5 series

MCU ROM CoreSight peripheral identity register 2 (MCUROM_PIDR2)

Address offset: 0xFE8

Reset value: 0x0000 000A

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

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

0x0: rev r0p0

Bit 3 JEDEC : JEDEC assigned value

1: designer identification specified by JEDEC

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

0x2: STMicroelectronics JEDEC code

MCU ROM CoreSight peripheral identity register 3 (MCUROM_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

MCU ROM CoreSight component identity register 0 (MCUROM_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 identification bits [7:0]

0x0D: Common identification value

MCU ROM CoreSight peripheral identity register 1 (MCUROM_PIDR1)

Address offset: 0xFF4

Reset value: 0x0000 0010

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

Bits 7:4 CLASS[3:0] : Component identification bits [15:12] - component class

0x1: ROM table component

Bits 3:0 PREAMBLE[11:8] : Component identification bits [11:8]

0x0: Common identification value

MCU ROM CoreSight component identity register 2 (MCUROM_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 identification bits [23:16]

0x05: common identification value

MCU ROM CoreSight component identity register 3 (MCUROM_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 identification bits [31:24]

0xB1: Common identification value

59.5.4 MCU ROM table register map

Table 729. MCU ROM table register map and reset values

Table 729. MCU ROM table register map and reset values (continued)

Refer to Table 726 for register boundary addresses.

59.5.5 Processor ROM table registers

CPU ROM memory type register (CPUROM_MEMTYPER)

Address offset: 0xFCC

Reset value: 0x0000 0001

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

Bit 0 SYSTEM : system memory

1: system memory present on this bus

CPU ROM CoreSight peripheral identity register 4 (CPUROM_PIDR4)

Address offset: 0xFD0

Reset value: 0x0000 0004

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

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

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

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

0x4: ARM ^® JEDEC continuation code

CPU ROM CoreSight peripheral identity register 0 (CPUROM_PIDR0)

Address offset: 0xFE0

Reset value: 0x0000 00C9

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

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

0xC9: Cortex ^® -M33

CPU ROM CoreSight peripheral identity register 1 (CPUROM_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 00B4

Bits 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]

0x4: Cortex®-M33

CPU ROM CoreSight peripheral identity register 2 (CPUROM_PIDR2)

Address offset: 0xFE8

Reset value: 0x0000 000B

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

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

0x0: rev r0p0

Bit 3 JEDEC : JEDEC assigned value

1: Designer ID specified by JEDEC

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

0x3: Arm® JEDEC code

CPU ROM CoreSight peripheral identity register 3 (CPUROM_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

CPU ROM CoreSight component identity register 0 (CPUROM_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 identification bits [7:0]

0x0D: Common identification value

CPU ROM CoreSight peripheral identity register 1 (CPUROM_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 identification bits [15:12] - component class

0x1: ROM table component

Bits 3:0 PREAMBLE[11:8] : Component identification bits [11:8]

0x0: Common identification value

CPU ROM CoreSight component identity register 2 (CPUROM_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 identification bits [23:16]

0x05: common identification value

CPU ROM CoreSight component identity register 3 (CPUROM_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 identification bits [31:24]

0xB1: common identification value

59.5.6 Processor ROM table register map

Table 730. CPU ROM table register map and reset values