78. Debug support (DBG)

78.1 DBG introduction

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

• • Independent breakpoint debugging of 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 (SWJ-DP), using industry standard debugging tools.

A trace port allows data to be captured for logging and analysis.

The debug features are based on the following Arm ^® CoreSight ^™ components:

• • SWJ-DP: JTAG/serial-wire debug port
• • AXI-AP: AXI access port
• • AHB-AP: AHB access port
• • APB-AP: APB access port
• • ITM: instrumentation trace macrocell
• • DWT: data watchpoint and trace
• • ETM: Embedded Trace Macrocell
• • ETF: embedded trace FIFO
• • ETR: embedded trace router
• • TPIU: trace port interface unit
• • SWO: serial-wire output
• • CTI: cross-trigger interface
• • CTM: cross-trigger matrix
• • Timestamp generator
• • STM: system trace macrocell

These components are described in Section 78.11 and Section 78.12 . More information can be found in the Arm documents referenced in Section 78.13 .

Debug use cases

The trace and debug system are designed to support a variety of typical use cases:

• • Low-cost software trace

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

• • External debugging

The software can be debugged using equipment connected to the JTAG/SWD debug port. This allows breakpoint and watchpoint settings, code stopping, and memory access.

• • Self-hosted debugging

Debug resources can be accessed by software running on the processor. This allows autonomous fault analysis, and communication with external tools via a functional interface (such as USB or UART). Halting the CPU is not possible.

• • Tracing code execution from via the trace port

The trace information is 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.

• • Code and hardware instrumentation via the trace port

The software data from the processor, memory content via DMA, and hardware event trace information can be generated using the STM. The information is combined with the processor trace stream, and output to a trace port analyzer in real time.

• • Capturing trace continuously into the ETF programmed as a circular buffer (ETB)

The combined trace information can be stored on-chip in a private circular buffer. The trace storage can be started and stopped by a debugger command, a software command, an external trigger signal, or an internal event.

• • Capturing trace continuously into a system memory

Thanks to the ETR, the combined trace information can be sent to a system memory. The trace storage can be started and stopped by a debugger command, a software command, an external trigger signal, or an internal event.

• • Reading the stored trace with the debugger

The debugger can read the contents of the recorded trace data 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.

• • Self-hosted trace analysis

The recorded trace data can be read by the Cortex-M55. This powerful feature allows built-in test software to monitor code execution in real time, analyze and identify faults, and autonomously handle exceptions.

• • Uploading stored trace

The stored trace can also be uploaded to a host machine using one of the communication 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.

78.2 DBG functional description

The debug infrastructure is composed of three subsystems:

• • The Cortex-M55 incorporates the following CoreSight components:
  • – SCS (system control space): contains registers used to identify and halt the processor. It accesses core data registers, and other debug features included in the processor core.
  • – DWT: generates trace or debug events on access to specific addresses
  • – BPU (breakpoint unit): allows the processor to be halted at specific addresses
  • – ITM: generates software instrumentation trace, and adds timestamp, synchronization, and DWT event trace packets
  • – ETM: generates non-intrusive program flow trace
  • – PMU (performance monitoring unit): counts events for performance analysis

• – CTI: allows cross-triggering between different trace and debug components
• – processor ROM table: allows a debugger to discover CoreSight components in the Cortex-M55
• • The trace and debug subsystem includes the following CoreSight components:
  • – ITM replicator: routes the ITM trace to both SWO and trace funnel
  • – SWO: provides a single-wire asynchronous trace port for low-bandwidth trace coming from the ITM
  • – CSTF (CoreSight trace funnel): merges trace from STM, ITM, and ETM
  • – ETF: smooths the trace stream by buffering in a local memory
  • – ETR replicator: routes trace from the CSTF to both ETR and TPIU
  • – ETR: routes trace to a buffer in the system RAM
  • – TPIU: provides a parallel trace port up to 16-bit wide for high-bandwidth trace coming from both ITM and ETM
  • – CTI: allows cross triggering between different trace and debug components
  • – system ROM table: allows a debugger to discover CoreSight components in the trace and debug subsystem
  • – DBGMCU (MCU debug unit): controls the debug authentication, the low-power mode emulation, and freezes certain peripherals in debug mode and other features
  • – STM: allows AXI bus masters to write trace data
• • The DAP (debug access port) allows an external debugger to access the debug and trace functionality. It contains the following CoreSight components:
  • – SWJ-DP: implements a JTAG interface as well as a serial-wire debug (SWD) interface together with debug port (DP) registers
  • – AHB-AP: AHB bus master that provides access to the trace and debug components in the Cortex-M55
  • – APB-AP: APB bus master that provides access to the trace and debug subsystem

78.3 DBG block diagram

Figure 1075. Block diagram of debug infrastructure

78.4 DBG pins

Table 855. SWJ-DP pins

Table 856. Trace port pins

Table 857. Serial-wire trace port pins

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

Table 858. Trigger pins

1. 1. DBTRGIO can be configured as an input or an output by DBTRGOEN in DBGMCU_CR. If configured as an input, it is connected to DBTRGIN. If configured as an output, it is connected to DBTRGOUT. This is because DBTRGIN and DBTRGOUT may not be available on some packages.

78.5 DBG power, clock, and reset

78.5.1 DBG power domains

Debug components are located in the core power domain. This means that a debug session is disconnected if the core is powered down (for example in Standby mode).

Debug and low-power modes

The device includes 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, a power-saving mode emulation is implemented.

If emulation is enabled for a domain, the domain still enters power-saving mode, but its clock and power are maintained: the domain behaves as in power-saving mode, but the debugger does not lose the connection.

This emulation mode is programmed in the DBGMCU (see Section 78.12.20 ).

78.5.2 DBG clocks

The debugger supplies the clock for the debug port (swtclk) via the debug interface pin JTCK/SWCLK. This clock is used to register the serial input data in both serial-wire and JTAG modes, as well as to operate state machines and internal logic of the debug port. This clock must therefore continue to toggle for at least five 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 system debug clock domain (ck_sys_dbg). All debug and trace components are in this same clock domain.

The ck_sys_dbg clock is enabled by the debugger using CDBGPWRUPREQ in DP_CTRLSTAT. It can also be enabled by software setting DBGCLKEN in DBGMCU_CR. This clock must be enabled before the debugger or software can access any of the debug features on the device. Disable this clock when debug and trace are not used, to reduce power consumption.

The TPIU output clock (ck_trace, also called traceclk) is generated by the RCC. Its frequency can be programmed to match the I/O port capability. This clock is also used to drive the SWO. It can only be enabled by setting TRACECLKEN in DBGMCU_CR.

Note: ck_trace must be activated whenever tracing is required, even if neither the TPIU nor the SWO are used (for example, when using the ETR as a software buffer). This avoids

filling up the SWO FIFO, which may then block the trace output from the ITM in the Cortex-M55.

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

78.5.3 Debug reset

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

The debug and trace components, including the Cortex-M55 debug part, can be reset in three different ways:

• • Over the DAP by setting CDBGIRSTREQ in DP_CTRLSTAT

Setting this bit asserts the debug reset request signal (cdbgrstreq) connected to the RCC. The RCC then activates rcc_dbg_rst, and returns a handshake signal (cdbgrstack) to acknowledge the DAP request. This acknowledge can be read by the debugger on CDBGIRSTACK in DP_CTRLSTAT. The rcc_dbg_rst is active as long as CDBGIRSTREQ is set.

• • By the application setting DBGIRST in RCC_MISCRSTR

When this bit is set, the rcc_dbg_rst is activated. It is released when DBGIRST is cleared.

• • When a POR occurs

The rcc_dbg_rst is activated after a power-on reset, or when the product exits Standby mode.

Figure 1076. Debug reset control logic

The rcc_dbg_rst can be applied only when the processor is in a quiescent state (when all system transactions have been completed, or when the processor is in debug mode).

78.6 Security

The trace and debug components allow a high degree of access to the processor, and system during product development. To protect user code, and to ensure that 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, a secure software debug and trace can be disabled without preventing the debug of non-secure code.

78.6.1 BSEC control over debug

The BSEC features the following registers dedicated to debug:

• • BSEC_AP_UNLOCK register

It can be used to open the debug access port to the Cortex-M55 (AP1) when a specific value is written in it. This register drives ap_unlocked[7:0] signals toward the debug logic that decodes these signals to open the access port if the expected value is met.

• • BSEC_DBGCR register

It can be used to enable the non-secure/secure debug when a specific value is written in it. This register drives dbg_unlocked_sec[7:0] and dbg_unlocked[7:0] signals toward the debug logic that decodes these signals to determine the values of the authentication signals (see the next section), enabling or not the debug for full secure or only non-secure world.

The BSEC also defines the HDPL (hide protection level) from which the debug is enabled. Its hardware ensures that dbg_unlocked and dbg_unlocked_sec automatically adopt the specific values as soon as the appropriate HDPL is reached.

On an open device, these registers are automatically set to the values that open the debug (refer to Section 4: Boot and security control (BSEC) for details on these registers.)

78.6.2 Authentication signals

The following authentication signals are used by a CoreSight system to determine which features are enabled or disabled. These signals are derived from the BSEC_DBGCR register value. This applies not only when the debug authentication sequence is executed, but also during the regular debug in open, closed, or closed secure states (refer to Section 3: System security for details on these states):

• • dbgen : global enable for all debug and trace features
  0: All debug features are disabled.
  1: Debug features in non-secure mode are enabled. Debug features in secure mode depend on the spiden state.
• • spiden : enables debug in secure privileged mode when dbgen = 1.
  0: Debug features are disabled in secure privileged mode. External access to secure system interconnect is disabled.
  1: Debug features are enabled in secure privileged mode. External access to secure system interconnect is enabled.
• • niden : enables trace and performance monitoring (non invasive debug).
  0: Trace generation is disabled.
  1: Trace generation in non-secure mode is enabled. Trace generation in non-secure mode depends on the spiden state.
• • spniden : enables trace and performance monitoring in secure privileged mode when niden = 1.
  0: Trace generation is disabled in secure privileged mode
  1: Trace generation is enabled in secure privileged mode

For detailed information on the Arm Coresight debug infrastructure, refer to the relevant component section, or to the relevant Arm technical documentation, which describes the dbgen, niden, spiden and spniden signals. When the BSEC_DBGCR register is configured

to enable debug (either secure or non-secure), the dbgen and niden signals are set. The spiden and spniden signals are only set if secure debug is enabled.

The initial states of the signals are set at POR, according to Table 859 . Signal states can be modified through an authentication process, by a trusted software with secure and privileged access rights, in collaboration with the debugger (see Section 78.7 for more details on the authentication process).

Table 859. Authentication signal initial states

78.7 Debug authentication

78.7.1 Main characteristics

The debug authentication relies on the fact that, even when debug is disabled, there is always an access port available (the APB-AP, AP0) to support communication between the host (debugger) and the device (STM32 product).

Debug rights (controlled by BSEC) are reset by a POR.

The debug authentication starts only at boot (HDPL1). This implies that a debugger hot plug is not possible on a closed part.

In BSEC-open state, the debugger can configure debug peripherals, and has full access to the system without the need for an authentication (but not to the fuse secrets, and unmapped ROM code).

During bootROM execution (HDPL0), the debug is automatically disabled via hardware.

When the debug is opened via a certificate, the debugger can proceed with debug infrastructure configuration. The debug certificate contains debugger access rights (secure, non-secure, HDPL).

When the debug is disabled, the debugger can still proceed with debug infrastructure 'discovery', but can only see the authentication mailbox. Other debug and trace features are disabled.

78.7.2 Debug authentication protocol

Principle

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 debugger (host) and the SoC (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 POR of the device, when an “open request” message is posted by the host. The protocol is based on the following steps:

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

After a first sequence of mutual authentication to align (on protocol version, or device type for example), the device generates a random value that must be signed by the host with a private key when building the response.

The device verifies the signed response including the random value using a public key embedded in the device.

Status mailbox

A mailbox status information is provided to inform host or device that a message is available for reading. This is especially useful when one side sends a message larger than 32 bits. For instance, when the device sends such a long message, it checks that the host has read each 32-bit element before writing a new one by polling the clear of DEVICE_ACK.

The DBGMCU_DBG_AUTH_ACK register is used for that purpose. This register is read only for the host and the device:

• • HOST_ACK: this bit is set when the host writes a message in DBGMCU_DBG_AUTH_HOST. It indicates that a new message is present in the mailbox. This bit is reset when the device reads DBGMCU_DBG_AUTH_HOST. The device can poll this bit to know when the host has written a message.
• • DEVICE_ACK: this bit is set when the device writes a message in DBGMCU_DBG_AUTH_DEV, and reset when the host reads it. The host can poll this bit to know when the device has written a new message.

78.8 Chip-level TAP controller (CLTAPC)

The JTAG interface is connected to the internal scan chain of the device. It is used for testing as well as for debug. The first component in the scan chain is the chip-level TAP controller, which implements a TAP state machine based on IEEE Std 1149.1-1990. It allows access to the built-in manufacturing test features.

The CLTAPC must be bypassed in order to access the debug support functions provided by the SWJ-DP. This is done by prefixing SWJ-DP instructions with the CLTAPC bypass instruction sequence (0b11111).

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

• • 5-pin standard JTAG interface (JTAG-DP)
• • 2-pin (clock + data) serial-wire debug port (SW-DP)

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

By default, the JTAG-DP is selected after a system or POR. 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.

78.9.1 JTAG debug port

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

Figure 1077. 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
    Capture-DR --> Shift-DR: JTMS=0
    Capture-DR --> Select-DR-Scan: JTMS=1
    Shift-DR --> Shift-DR: JTMS=0
    Shift-DR --> Exit1-DR: JTMS=1
    Exit1-DR --> Select-DR-Scan: JTMS=1
    Exit1-DR --> Select-IR-Scan: JTMS=1
    Exit1-DR --> Pause-DR: JTMS=0
    Exit1-DR --> Exit2-DR: JTMS=0
    Exit1-DR --> Update-DR: JTMS=0
    Pause-DR --> Shift-DR: JTMS=0
    Pause-DR --> Select-DR-Scan: JTMS=1
    Pause-DR --> Select-IR-Scan: JTMS=1
    Pause-DR --> Exit2-DR: JTMS=0
    Pause-DR --> Update-DR: JTMS=0
    Exit2-DR --> Select-DR-Scan: JTMS=1
    Exit2-DR --> Select-IR-Scan: JTMS=1
    Exit2-DR --> Update-DR: JTMS=0
    Update-DR --> Run-Test/Idle: JTMS=1
    Update-DR --> Select-DR-Scan: JTMS=0
    Select-IR-Scan --> Capture-IR: JTMS=0
    Select-IR-Scan --> Select-DR-Scan: JTMS=1
    Capture-IR --> Shift-IR: JTMS=0
    Capture-IR --> Select-IR-Scan: JTMS=1
    Shift-IR --> Shift-IR: JTMS=0
    Shift-IR --> Exit1-IR: JTMS=1
    Exit1-IR --> Select-IR-Scan: JTMS=1
    Exit1-IR --> Pause-IR: JTMS=0
    Exit1-IR --> Exit2-IR: JTMS=0
    Exit1-IR --> Update-IR: JTMS=0
    Pause-IR --> Shift-IR: JTMS=0
    Pause-IR --> Select-IR-Scan: JTMS=1
    Pause-IR --> Exit2-IR: JTMS=0
    Pause-IR --> Update-IR: JTMS=0
    Exit2-IR --> Select-IR-Scan: JTMS=1
    Exit2-IR --> Update-IR: JTMS=0
    Update-IR --> Run-Test/Idle: JTMS=1
    Update-IR --> Select-DR-Scan: JTMS=0
  

MSV39776V1

When the TAPSM goes through the Capture-IR state, 0b0001 is transferred into the IR scan chain connected between JTDI and JTDO.

While the TAPSM is in the Shift-IR state, the IR scan chain shifts one bit for each JTCK rising edge. 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 DR to one of the DR scan chains, connected between JTDI and JTDO.

The value held in the instruction register determines which DR and associated DR scan chain are selected.

Data are 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 DR.

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 table below lists DRs corresponding to the 4-bit IR instructions.

Table 860. JTAG-DP data registers

Table 860. JTAG-DP data registers (continued)

For more details on DR registers and the JTAG debug protocol, refer to the Arm Debug Interface Architecture Specification [1].

78.9.2 SWD debug port

The serial-wire debug protocol uses the two following pins:

• • SWCLK: clock from the host (debugger) to the device (STM32 product)
• • SWDIO: bidirectional serial data (with internal pull-up)

Serial data are transferred LSB first, synchronously with the clock. A transfer comprises the following 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 (for a write) or the device (for 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 861. Packet request

Table 862. ACK response

Table 863. Data transfer

Figure 1078 shows successful write and read transfers.

Figure 1078. SWD successful data transfer

For any FAULT or WAIT ACK response from the device, the data transfer phase is canceled, unless overrun detection is enabled. If and overrun detection is enabled, data are ignored by the device (for a write), or not driven (for 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.

78.9.3 Debug port registers

The SW-DP and JTAG-DP access the debug port (DP) registers, listed in Table 864 .

The debugger can access DP registers as follows:

1. 1. Program DPBANKSEL in DP_SELECT to select the register bank to be accessed (see Table 864 ).
2. 2. If using JTAG, program A[3:2] in the DPACC register with the register address within the bank. Program the R/W bit to select a read or a write. For 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 861 ). The write data are sent in the data phase.

Table 864. 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: 0x0

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 STICKYORUN in DP_CTRLSTAT.

Bit 3 WDERRCLR : Write data error clear bit

0: No effect

1: Clear WDATAERR in DP_CTRLSTAT.

Bit 2 STKERRCLR : Sticky error clear bit

0: No effect

1: Clear STICKYERR in DP_CTRLSTAT.

Bit 1 STKCMPCLR : Sticky compare clear bit

0: No effect

1: Clear STICKYCMP in DP_CTRLSTAT.

Bit 0 DAPABORT : Abort current AP transaction

The transaction is aborted if an excessive number of WAIT responses are returned.

This indicates that the transaction has stalled.

0: No effect

1: Abort the transaction.

Debug port control/status register (DP_CTRLSTAT)

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, this field is loaded with the number of transactions to perform. It is decremented on successful completion of each transaction.

The field indicates the bytes to be masked in pushed-compare and pushed-verify operations (TRNMODE = 1 or 2 in this register). In the pushed operations, the word supplied in an AP write transaction is compared with the current value at the target AP address.

1xxx: Include byte lane 3 in comparisons.

x1xx: Include byte lane 2 in comparisons.

xx1x: Include byte lane 1 in comparisons.

xxx1: Include byte lane 0 in comparisons.

The bit indicates one of the following:

• – a parity or a framing error on the data phase of a write operation
• – a write operation that had been accepted by the DP, and then discarded without being submitted to the AP

This bit is read-only. It is reset by writing 1 to WDERRCLR in DP_ABORT.

0: No error

1: Error has occurred.

Note: This bit is reserved in JTAG-DP.

This bit indicates the response to the last AP read access. It is read-only.

0: Read not ok

1: Read ok

Note: This bit is reserved in JTAG-DP.

This bit indicates that an error occurred during an AP transaction. In SW-DP, this bit is reset by writing 1 to STKERRCLR in DP_ABORT. In JTAG-DP, this bit is reset by programming it to 1.

0: No error

1: Error has occurred.

This bit indicates that a match occurred in a pushed operation. In SW-DP, this bit is reset by writing 1 to STKCMPCLR in DP_ABORT. In JTAG-DP, this bit is reset by programming it to 1.

0: Match if TRNMODE = 0x1; no match if TRNMODE = 0x2

1: No match if TRNMODE = 0x1; match if TRNMODE = 0x2

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 in this register.

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

Note: In pushed operations, only the data bytes indicated by the MASKLANE field are included in the comparison.

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

This bit indicates that an overrun occurred (a new transaction received before previous transaction completed). This bit is only set if ORUNDETECT is set in this register. In SW-DP, this bit is reset by writing 1 to ORUNERRCLR in DP_ABORT. In JTAG-DP, this bit is reset by writing a 1 to it.

0: No overrun

1: Overrun occurred.

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 STICKYORUN 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: 0x0486 0041

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

0x0: revision 1

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

0x4860: STM32N6x5/x7xx

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

0x020: STMicroelectronics

Bit 0 Reserved, must be kept at reset value.

Debug port data link protocol identification register (DP_DLPIDR)

Address offset: 0x4

Reset value: 0x0000 0001

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

These bits define the instance number for this device in a multi-drop system: 0x0.

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

Bits 3:0 PROTSVN[3:0] : Serial-wire debug protocol version

0x1: Version 2

Debug port resend register (DP_RESEND)

Address offset: 0x8

Reset value: 0x0000 0000

Bits 31:0 RESEND[31:0] : Last AP read or DP RDBUFF read value

These bits contain the value that was returned by the last AP read or DP RDBUFF read. Used in the event of a corrupted read transfer.

Debug port access port select register (DP_SELECT)

Address offset: 0x8

Reset value: 0xXXXX XXXX

Bits 31:24 APSEL[7:0] : Access port select bits

These bits select the access port for the next transaction.

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

0x01: AP1 - Cortex-M55 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 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: DP_CTRLSTAT register

0x1: DP_DLCR register

0x2: DP_TARGETID register

0x3: DP_DLPIDR register

Others: 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./
• – Read the value returned by the last AP read access from the DP_RDBUFF register, in which case no new AP transaction occurs.

Debug port target identification register (DP_TARGETSEL)

Address offset: 0xC

Reset value: 0xXXXX XXXX

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

This field defines the instance number for the target device in a multi-drop system. It must be programmed with the same value as TINSTANCE in DP_DLPIDR in order to select this device.

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

This field defines the part number for the target device. It must be programmed with the same value as TPARTNO in DP_TARGETID in order to select this device.

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

This field defines the JEDEC code for the target device. It must be programmed with the same value as TDESIGNER in DP_TARGETID in order to select this device.

Bit 0 Reserved, must be kept at reset value.

Debug 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 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 865. Debug port register map and reset values

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

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

78.10 Access ports

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

Figure 1079. Debug and access port connections

    graph LR
      JTAG_SWD[JTAG/SWD] <--> SWJ_DP[SWJ-DP]
      SWJ_DP <--> DAPBUS[DAPBUS]
      DAPBUS --> AP0[AP0
(APB-AP)]
      DAPBUS --> AP1[AP1
(AHB-AP)]
      DAPBUS --> AP2[AP2
(AXI-AP)]
      AP0 <--> DBGMCU[DBGMCU]
      AP1 <--> Cortex_M55[Cortex-M55]
      AP2 <--> System_Interconnect[System interconnect (AXI)]
  

• • AP0 debug access port to DBGMCU (APB-AP): is always accessible during reset so that a debugger can initiate an authentication process even if it is a closed device.
• • AP1 Cortex-M55 access port (AHB-AP): allows access to the debug and trace features integrated in the Cortex-M55 processor via its PPB bus, and all other debug

components located on the EPPB interface (external private peripheral bus). In a closed device, AP1 is locked until the debug authentication process is complete.

• • AP2 system bus access port (AXI-AP): Allows access to the system bus matrix, which gives visibility of all the memory and peripherals accessible via the AXI interconnect. In a closed device, AP2 is locked until the debug authentication process is complete.

All access ports are of MEM-AP type: 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 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 860 ) or of the SW-DP packet request (see Table 861 ), depending on the debug interface used
• • bits [1:0]: Always set to 0

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

The debugger can access the AP registers as follows:

• • Program APSEL field in DP_SELECT to choose one of the APs, and APBANKSEL field to select the register bank to be accessed.
• • If using JTAG, program A[3:2] field in the APACC register with the register address within the bank. Program the RnW bit to select a read or a write. For 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 861 ). The write data are 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 APx_TAR.
2. 2. Program APx_CSW, if necessary, with the transfer parameters (AddrInc for example).
3. 3. Write to or read from APx_DRW to initiate a bus transaction at the address held in the APx_TAR register. Alternatively, a read or write to banked data register BDN triggers an access to address TAR[31:4] + n (this allows an access to the next four consecutive addresses without changing the address in APx_TAR).

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

Authentication

The effect of the authentication signals for AP1 and AP2 is shown in Table 866 .

Table 866. AP1-2 authentication behavior

78.10.1 AP0 registers

Access port 0 control/status word register (AP0_CSW)

Address offset: 0x0

Reset value: 0x8000 0002

Bit 31 DBGSWENABLE : Software debug enable

This bit enables or disables software access to the APB bus via the APB interconnect. It must always be set to 1 to enable software access to the DBGMCU.

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

0x0: Normal download or upload model.

Others: reserved

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

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 in this register).

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

AP0 transfer address register (AP0_TAR)

Address offset: 0x04

Reset value: 0x0000 0000

Bits 31:0 ADDRESS[31:0] : address of the current transfer

AP0 data read/write register (AP0_DRW)

Address offset: 0x0C

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : read/write data for current transfer

In write mode, this is the write data value. In read mode, this is the read data value.

AP0 banked data register x (AP0_BDx)

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

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : Read/write data for current transfer

The transaction address is \( TAR[31:4] \ll 4 + 0x4 * x \) .

AP0 base address register (AP0_BASE)

Address offset: 0xF8

Reset value: 0x8000 0003

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

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

0x800000: ROM table base address is 0x8000 0000

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

This bit indicates that debug components are present on the access port bus:

1: Debug components are present.

AP0 identification register (AP0_IDR)

Address offset: 0xFC

Reset value: 0x5477 0002 (AP0)

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

0x5: r1p0

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

0x02: APB-AP

AP0 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 APBANKSEL[3:0] in DP_SELECT and by JTAG-DP register DPACC or SW-DP packet request A[3:2] field.

Table 867. AP0 register map and reset values

78.10.2 AP1 registers

Access port 1 control/status word register (AP1_CSW)

Address offset: 0x0

Reset value: 0x4000 0002

Bit 31 Reserved, must be kept at reset value.

Bit 30 SPROT : Secure transfer request

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

0: If spiden is high, secure transfer. If spiden is low, no transfer.

1: Nonsecure transfer

Bit 29 Reserved, must be kept at reset value.

Bits 28:24 PROT[4:0] : Bus transfer protection

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

xxxx0: Instruction fetch

xxxx1: Data access

xxx0x: User mode

xxx1x: Privileged mode

xx0xx: Non-bufferable

xx1xx: Bufferable

x0xxx: Non-cacheable

x1xxx: Cacheable

0xxxx: Non-exclusive

1xxxx: Exclusive

Bit 23 SPISTATUS : Status of spiden authentication signal

This bit determines whether the debugger can access secure memory.

0: Secure AHB transfers not supported

1: Secure AHB transfers allowed

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

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

0x0: Normal download or upload mode

Others: reserved

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 DBGSTATUS : Debug status

Indicates the state of the dbgen authentication signal

0: No AHB transfers permitted

1: AHB transfers permitted

Bits 5:4 ADDRINC[1:0] : Auto-increment mode

These bits define whether the TAR address is automatically incremented after a transaction.

0x0: No auto-increment

0x1: Address incremented by the size in bytes of the transaction (SIZE field)

0x2: Packed transfers enabled. 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. 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: Half-word (16-bit)
0x2: Word (32-bit)
Others: Reserved

AP1 transfer address register (AP1_TAR)

Address offset: 0x04

Reset value: 0x0000 0000

Bits 31:0 ADDRESS[31:0] : Address of the current transfer

AP1 data read/write register (AP1_DRW)

Address offset: 0x0C

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : Read/write data for current transfer

In write mode, this is the write data value. In read mode, this is the read data value.

AP1 banked data register x (AP1_BDx)

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

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : read/write data for current transfer

The transaction address is TAR[31:4] << 4 + 0x4 * x.

AP1 base address register (AP1_BASE)

Address offset: 0xF8

Reset value: 0xE00F E003

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

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

0xE00FE: ROM table base address is at 0xE00F E000.

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

This bit indicates that debug components are present on the access port bus:

1: Debug components are present.

AP1 identification register (AP1_IDR)

Address offset: 0xFC

Reset value: 0x8477 0001 (AP1)

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

0x8: r0p9

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

AP1 register map

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

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

Table 868. AP1 register map and reset values

78.10.3 AP2 registers

AP2 control/status word register (AP2_CSW)

Address offset: 0x0

Reset value: 0x30X0 60X2

Bit 31 Reserved, must be kept at reset value.

Bits 30:28 PROT[2:0] : Access permissions

This field sets ARPROT[2:0] or AWPROT[2:0] attributes of the bus transfer.

xx0: Unprivileged access

xx1: Privileged access

x0x: Secure access

x1x: Nonsecure access

0xx: Data access

1xx: Instruction access

Bits 27:24 CACHE[3:0] : Memory type

This field sets ARCACHE[3:0] or AWCACHE[3:0] attributes of the bus transfer (see AMBA AXI and ACE Protocol Specification [7]).

Bit 23 SPISTATUS : Status of spider authentication signal

This bit determines whether the debugger can access secure memory.

0: Secure AXI transfers not supported

1: Secure AXI transfers are allowed.

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

Bits 14:13 DOMAIN[1:0] : Shareable transaction encoding for ACE

0: Non-shareable

1: Shareable, inner domain, includes additional masters.

2: Shareable, outer domain, also includes inner or additional masters.

3: Shareable, system domain, all masters included

Bit 12 ACEENABLE : Enable ACE transactions, including barriers

0: Disable

1: Enable

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

0x0: Normal download or upload

0x1: Barrier transaction

Others: Reserved

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 DBGSTATUS : Debug status

This bit indicates the state of the dbgen authentication signal

0: No AXI transfers permitted

1: AXI transfers are permitted.

Bits 5:4 ADDRINC[1:0] : Auto-increment mode

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

0x0: Byte (8-bit)

0x1: Half-word (16-bit)

0x2: Word (32-bit)

0x3: Double word (64-bit)

Others: Reserved

AP2 transfer address register (AP2_TAR)

Address offset: 0x04

Reset value: 0x0000 0000

Bits 31:0 ADDRESS[31:0] : Address of the current transfer

AP2 data read/write register (AP2_DRW)

Address offset: 0x0C

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : Read/write data for current transfer

In write mode, this is the write data value. In read mode, this is the read data value.

For 64-bit transfers, two accesses must be made to DRW for a single 64-bit AXI access.

The first access in read mode initiates the read on the AXI bus and returns the lower 32-bit word of data. The second access returns the upper 32-bit word. In write mode, the first access contains the lower 32-bit word of data, the second access contains the upper 32-bit word and initiates the write on the AXI bus.

AP2 banked data register x (AP2_BDx)

Address offset: \( 0x10 + 0x4 \times x \) ( \( x = 0 \) to \( 3 \) )

Reset value: 0x0000 0000

Bits 31:0 DATA[31:0] : Read/write data for current transfer
The transaction address is \( TAR[31:4] \ll 4 + 0x4 \times x \) .
64-bit banked data transactions are not supported

AP2 configuration register (AP2_CONFIG)

Address offset: 0xF4

Reset value: 0x0000 0002

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

• Bit 2 LD : Large data support
  1: 64-bit data transfers supported
• Bit 1 LA : Long address support
  0: 32-bit address only
• Bit 0 BE : Big-endian
  0: Little-endian

AP2 base address register (AP2_BASE)

Address offset: 0xF8

Reset value: 0x0000 0002

Bits 31:12 BASEADDR[19:0] : Base address (bits 31 to 12) of the AP ROM table
Not applicable, no ROM table present

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
This bit indicates that debug components are present on the access port bus:
0: No debug components are present.

AP2 identification register (AP2_IDR)

Address offset: 0xFC

Reset value: 0x4477 0004

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

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
0x04: AXB-AP

AP2 register map

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

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

Table 869. AP2 register map and reset values

78.10.4 ROM tables

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

The system ROM table is pointed to by the AP0 base register. 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 0x8000 0000 to 0x8000 0FFC when accessed by the debugger.

Alternatively, it can be accessed by the CPU at address range 0x4400 0000 to 0x4400 0FFF.

1. Not CoreSight compatible. Bit 0 is reset to indicate that there are no CoreSight registers in this component.

The MCU ROM table is pointed to by the AP1 base register. It contains the base address pointer for the Cortex-M55 ROM table and for the trace subsystem ROM table.

It occupies a 4-Kbyte, 32-bit wide chunk of address space, from 0xE00F E000 to 0xE00F EFFF.

The top of ROM tables contains a number of read-only registers, including the standard CoreSight component and peripheral identity registers (see Section 78.10.5 ).

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.

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 address space containing the CoreSight identity registers for the component.

1. 3. Read the peripheral ID4 (PIDR4) register for the component. The address of this register is:

1. 4. Extract the SIZE[7:4] field from the value of the peripheral ID4 register. This gives the number of 4-Kbyte sections of address space occupied by the component.

1. 5. Use the SIZE field value to calculate the start address of the address space for the component:

\( \text{Component\_Start\_Address} = \text{Component\_Base\_Address} - \text{SIZE} \times 0\text{x1000} \) . If the field value is 0b0000, which corresponds to one 4-Kbyte section, the address space for the component starts at Component_Base_Address obtained at stage 2.

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

78.10.5 System/MCU 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 SYSTM : 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 SIZE[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 0099

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

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

0x86: STM32N6 device

SYSROM CoreSight peripheral identity register 1 (SYSROM_PIDR1)

Address offset: 0xFE4

Reset value: 0x0000 0004

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: STM32N6x5/x7xx device

Address offset: 0xFE8

Reset value: 0x0000 001A

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

0x0: Not used

1: Designer ID specified by JEDEC

0x2: STMicroelectronics JEDEC code

Address offset: 0xFEC

Reset value: 0x0000 0000

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

0x0: No metal fix

0x0: No customer modifications

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

Table 872. System ROM table register map and reset values

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

78.11 Cortex-M55 debug features

The Cortex-M55 integrates the following CoreSight components:

• • Cortex-M55 ROM table
• • Cortex-M55 SCS (system control space)
• • BPU (breakpoint unit)
• • DWT (data watchpoint and trace unit)
• • ITM (instrumentation trace macrocell)
• • ETM (Embedded Trace Macrocell)
• • CTI (cross trigger interface)

These components are accessible by the debugger via the Cortex-M55 AHB-AP.

78.11.1 Processor ROM table

The MCU ROM table in the Cortex-M55 sub-system pointed to by the BASE register in the Cortex-M55 AHB-AP links to the Cortex-M55 processor ROM table.

Table 873 contains the base address pointer for the SCS registers, which allows the debugger to identify the CPU core, as well as for the FPB, DWT, ITM, ETM, and CTI.

The Cortex-M55 processor ROM table occupies a 4-Kbyte, 32-bit wide chunk of address space, from 0xE00FF000 to 0xE00FFFFC.

Table 873. Processor ROM table

Table 873. Processor ROM table (continued)

1. 1. The TPIU is included in this table by default, but bit 0 is reset to indicate that it is not present.
2. 2. The PMC-100 is included in this table by default, but bit 0 is reset to indicate that it is not present.

The topology for the debug components in the Cortex-M55 subsystem is shown in Figure 1080 .

Figure 1080. Cortex-M55 debug topology

78.11.2 Processor ROM registers

Processor ROM memory type register (CPUROM_MEMTYPE)

Address offset: 0xFCC

Reset value: 0x0000 0001

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

Bit 0 SYSTMEM : System memory presence

1: System memory is present on this bus.

Processor 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: Register file occupies a single 4-Kbyte region.

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

0x4: Arm JEDEC continuation code

Processor ROM CoreSight peripheral identity register 0 (CPUROM_PIDR0)

Address offset: 0xFE0

Reset value: 0x0000 00D2

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

Bits 7:0 PARTNUM[7:0] : Part number field, bits [7:0]
0xD2: Cortex-M55 processor ROM table

Processor 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 field, bits [3:0]
0xB: Arm JEDEC code

Bits 3:0 PARTNUM[11:8] : Part number field, bits [11:8]
0x4: Cortex-M55 processor ROM table

Processor 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 field, bits [6:4]
0x3: Arm JEDEC code

Processor 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

Processor 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 ID field, bits [7:0]

0x0D: Common ID value

Processor ROM CoreSight component 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 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

Processor 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 ID field, bits [23:16]

0x05: Common ID value

Processor 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 ID field, bits [31:24]

0xB1: Common ID value

Processor ROM register map

Table 874. Processor ROM register map and reset values

Table 874. Processor ROM register map and reset values (continued)