3. Processor subsystem

Figure 6. The RP2350 processor subsystem connects two processors to the system bus, peripheral interrupts, GPIOs, and a Serial Wire Debug (SWD) connection from an external debug host. It also contains closely-coupled peripherals, and peripherals used for synchronisation and communication, which are collectively referred to as the single-cycle IO subsystem (SIO).

RP2350 is a symmetric dual-core system. Two cores operate simultaneously and independently, offering high processing throughput and the ability to route interrupts to different cores to improve throughput and latency of interrupt handling. The two cores have a symmetric view of the system bus; all memory resources on RP2350 are accessible equally on both cores, with the same performance.

Each core has a pair of 32-bit AHB5 links to the system bus. One is used exclusively for instruction fetch, the other exclusively for load or store instructions and debugger access. Each core can perform one instruction fetch and one load or store access per cycle, provided there are no conflicts on the downstream bus ports.

There are two sockets for cores to attach to the system bus, referred to as core 0 and core 1 throughout this datasheet. (They may synonymously be referred to as core0, core1, proc0 and proc1 in register documentation.) The processor plugged into each socket is selectable at boot time:

• • A Cortex-M33 processor, implementing the Armv8-M Main instruction set, plus extensions
• • A Hazard3 processor, implementing the RV32IMAC instruction set, plus extensions

Cortex-M33 is the default option. Whichever processor is unused is held in reset with its clock gated at the top level. Unused processors use zero dynamic power. See Section 3.9 for information about the architecture selection hardware.

The two Cortex-M33 instances are identical. They are configured with the Security, DSP and FPU extensions, as well as 8x SAU regions, 8x Secure MPU regions and 8x Non-secure MPU regions. Section 3.7 documents the Cortex-M33 processor as well as the specific configuration used on RP2350. The two Hazard3 instances are also identical to one another; see Section 3.8 for the features and operation of the Hazard3 processors.

The Cortex-M33 implementation of the Armv8-M Security extension (also known as TrustZone-M) isolates trusted and untrusted software running on-device. RP2350 extends the strict partitioning of the Arm Secure and Non-secure states throughout the system, including the ability to assign peripherals, GPIOs and DMA channels to each security domain. See Section 10.2 for a high-level overview of Armv8-M Security extension features in the context of the RP2350 security architecture.

Not shown on Figure 6 are the coprocessors for the Cortex-M33. These are closely coupled to the core, offering a transfer rate of 64 bits per cycle in and out of the Arm register file. You may consider them to be inside the Cortex-M33 block on the diagram. RP2350 equips each Cortex-M33 with the following coprocessors:

• • Coprocessor 0 : GPIO coprocessor (GPIOC), described in Section 3.6.1
• • Coprocessors 4 and 5 : Secure and Non-secure instances of the double-precision coprocessor (DCP), described in Section 3.6.2
• • Coprocessor 7 : redundancy coprocessor (RCP), described in Section 3.6.3

An external debug host can access both cores over a Serial Wire Debug (SWD) bus. The host can:

• • run, halt and reset the cores
• • inspect internal core state such as registers
• • access memory from the core's point of view
• • load code onto the device and run it

Section 3.5 describes the debug hardware in addition to the instruction trace hardware available on the Arm processors.

Peripherals throughout the system assert interrupt requests (IRQs) to demand attention from the processors. For example, a UART peripheral asserts its interrupt when it has received a character, so the processor can collect it from the receive FIFO. All interrupts route to both cores, and the core's internal interrupt controller selects the interrupt signals it wishes to subscribe to. Section 3.2 defines the system-level IRQ numbering as well as details of the Arm non-maskable interrupt (NMI).

The event signals described in Section 3.3 are a mechanism for processors to sleep when waiting for other processors in the system to complete a task or free up some resource. Each processor sees events emitted by the other processor. They also see exclusivity events generated by the Global Exclusive Monitor described in Section 2.1.6 , which is the piece of hardware that allows the processors to safely manipulate shared variables using atomic read-modify-write sequences.

3.1. SIO

The Single-cycle IO subsystem (SIO) contains peripherals that require low-latency, deterministic access from the processors. It is accessed via the AHB Fabric. The SIO has a dedicated bus interface for each processor, as shown in Figure 7 .

Figure 7. The single-cycle IO block contains registers which processors must access quickly. FIFOs, doorbells and spinlocks support message passing and synchronisation between the two cores. The shared GPIO registers provide fast, direct access to GPIO-capable pins. Interpolators can accelerate common software tasks. Most SIO hardware is banked (duplicated) for Secure and Non-secure access. Grey arrows show bus connections for Non-secure access.

The SIO contains:

• • CPUID registers which read as 0/1 on core 0/1 ( Section 3.1.2 )
• • Mailbox FIFOs for passing ordered messages between cores ( Section 3.1.5 )
• • Doorbells for interrupting the opposite core on cumulative and unordered events ( Section 3.1.6 )
• • Hardware spinlocks for implementing critical sections without using exclusive bus accesses ( Section 3.1.4 )
• • Interpolators ( Section 3.1.10 ) and TMDS encoders ( Section 3.1.9 )
• • Standard RISC-V 64-bit platform timer ( Section 3.1.8 ) which is usable by both Arm and RISC-V software
• • GPIO registers for fast software bitbanging ( Section 3.1.3 ), with shared access from both cores

Most SIO hardware is duplicated for Secure/Non-secure access. Non-secure access to the FIFO registers will see a physically different FIFO than Secure access to the same address, so that messages belonging to Secure and Non-secure software are not mixed: Section 3.1.1 describes this Secure/Non-secure banking in more detail.

3.1.1. Secure and Non-secure SIO

To allow isolation of Secure and Non-secure software, whilst keeping a consistent programming model for software written to run in either domain, the SIO is duplicated into a Secure and a Non-secure bank. Most hardware is duplicated between the two banks, including:

• • Mailbox FIFOs
• • Doorbell registers

• • Interrupt outputs to processors
• • Spinlocks

For example, Non-secure code on core 0 can pass messages to Non-secure code on core 1 through the Non-secure instance of the mailbox FIFO. In turn, this message will generate a Non-secure interrupt, which is separate from the Secure FIFO interrupt line. This does not interfere with any Secure message passing that might be going on at the same time, and Non-secure code can not snoop Secure messages because it does not have access to the Secure mailboxes. The software running in the Secure and Non-secure domain can be identical, and the processors' bus accesses to the SIO will automatically be routed to the Secure or Non-secure version of the mailbox registers.

The following hardware is not duplicated:

• • The GPIO registers are shared, and Non-secure accesses are filtered on a per-GPIO basis by the Non-secure GPIO mask defined in the ACCESSCTRL GPIO_NSMASK0 and GPIO_NSMASK1 registers
• • The RISC-V standard platform timer ( MTIME , MTIMEH ), which is also usable by Arm processors, is present only in the Secure SIO, as it is a Machine-mode peripheral on RISC-V
• • The interpolator and TMDS encoder peripherals are assignable to either the Secure or Non-secure SIO using the PERL_NONSEC register

Accesses to the SIO register address range, starting at 0xd0000000 ( SIO_BASE ), are mapped to the SIO bank which matches the security attribute of the bus access. This means accesses from the Arm Secure state, or RISC-V Machine mode, will access the Secure SIO bank, and accesses from the Arm Non-secure state, or RISC-V User mode, will access the Non-secure SIO bank.

Additionally, Secure accesses can use the mirrored address range starting at 0xd0020000 ( SIO_NONSEC_BASE ) to access the Non-secure view of SIO, for example, using the Non-secure doorbells to interrupt Non-secure code running on the other core. Attempting to access this address range from Non-secure code will generate a bus fault.

i NOTE

The 0x20000 offset of the Secure-to-Non-secure mirror matches the PPB mirrors at 0xe0000000 ( PPB_BASE ) and 0xe0020000 ( PPB_NONSEC_BASE ), which function similarly.

i NOTE

Debug access is mapped to the Secure/Non-secure SIO using the security attribute of the debugger's bus access, which may differ from the security state that the core was halted in.

3.1.2. CPUID

The CPUID SIO register returns a value of 0 when read by core 0, and 1 when read by core 1. This helps software identify the core running the current application. The initial boot sequence also relies on this check: both cores start running simultaneously, core 1 goes into a deep sleep state, and core 0 continues the main boot sequence.

i IMPORTANT

Don't confuse the SIO CPUID register with the Cortex-M33 CPUID register on each processor's internal Private Peripheral Bus, which lists the processor's part number and version.

Reading the MHARTID CSR on each Hazard3 core returns the same values as CPUID : 0 on core 0, and 1 on core 1.

3.1.3. GPIO control

The SIO GPIO registers control GPIOs which have the SIO function selected (function 5). This function is supported on the following pins:

• • All user GPIOs (GPIOs 0 through 29, or 0 through 47, depending on package option)
• • QSPI pins
• • USB DP/DM pins

All SIO GPIO control registers come in pairs. The lower-addressed register in each pair (for example, GPIO_IN ) is connected to GPIOs 0 through 31, and the higher-addressed register in each pair (for example, GPIO_HI_IN ) is connected to GPIOs 32 through 47, the QSPI pins, and the USB DP/DM pins.

To drive a pin with the SIO's GPIO registers, the GPIO multiplexer for this pin must first be configured to select the SIO GPIO function. See Table 646 .

These GPIO registers are shared between the two cores: both cores can access them simultaneously. There are three groups of registers:

• • Output registers, GPIO_OUT and GPIO_HI_OUT set the output level of the GPIO. 0 for low output, 1 for high output.
• • Output enable registers, GPIO_OE and GPIO_HI_OE , are used to enable the output driver. 0 for high-impedance, 1 for drive high or low based on GPIO_OUT and GPIO_HI_OUT .
• • Input registers, GPIO_IN and GPIO_HI_IN , allow the processor to sample the current state of the GPIOs.

Reading GPIO_IN returns up to 32 input values in a single read, and software then masks out individual pins it is interested in.

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_gpio/include/hardware/gpio.h Lines 869 - 879

869 static inline bool gpio_get(uint gpio) {
870     #ifdef NUM_BANK0_GPIOS <= 32
871         return sio_hw->gpio_in & (1u << gpio);
872     #else
873         if (gpio < 32) {
874             return sio_hw->gpio_in & (1u << gpio);
875         } else {
876             return sio_hw->gpio_hi_in & (1u << (gpio - 32));
877         }
878     #endif
879 }

The OUT and OE registers also have atomic SET , CLR , and XOR aliases. This allows software to update a subset of the pins in one operation. This ensures safety for concurrent GPIO access, both between the two cores and between a single core's interrupt handler and foreground code.

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_gpio/include/hardware/gpio.h Lines 918 - 924

918 static inline void gpio_set_mask(uint32_t mask) {
919     #ifdef PICO_USE_GPIO_COPROCESSOR
920         gpior_lo_out_set(mask);

921 #else
922     sio_hw->gpio_set = mask;
923 #endif
924 }

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_gpio/include/hardware/gpio.h Lines 965 - 971

965 static inline void gpio_clr_mask(uint32_t mask) {
966 #ifdef PICO_USE_GPIO_COPROCESSOR
967     gpioc_lo_out_clr(mask);
968 #else
969     sio_hw->gpio_clr = mask;
970 #endif
971 }

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_gpio/include/hardware/gpio.h Lines 1155 - 1180

1155 static inline void gpio_put(uint gpio, bool value) {
1156 #ifdef PICO_USE_GPIO_COPROCESSOR
1157     gpioc_bit_out_put(gpio, value);
1158 #elif NUM_BANK0_GPIOS <= 32
1159     uint32_t mask = 1ul << gpio;
1160     if (value)
1161         gpio_set_mask(mask);
1162     else
1163         gpio_clr_mask(mask);
1164 #else
1165     uint32_t mask = 1ul << (gpio & 0x1fu);
1166     if (gpio < 32) {
1167         if (value) {
1168             sio_hw->gpio_set = mask;
1169         } else {
1170             sio_hw->gpio_clr = mask;
1171         }
1172     } else {
1173         if (value) {
1174             sio_hw->gpio_hi_set = mask;
1175         } else {
1176             sio_hw->gpio_hi_clr = mask;
1177         }
1178     }
1179 #endif
1180 }

If both processors write to an OUT or OE register (or any of its SET/CLR/XOR aliases) on the same clock cycle, the result is as though core 0 wrote first, then core 1 wrote immediately afterward. For example, if core 0 SETs a bit and core 1 XORs it on the same clock cycle, the bit ends up with a value of 0 .

This is a conceptual model for the result produced when two cores write to a GPIO register simultaneously. The register never contains the intermediate values at any point. In the previous example, if the pin is initially 0, and core 0 performs a SET while core 1 performs a XOR , the GPIO output remains low throughout the clock cycle.

As well as being shared between cores, the GPIO registers are also shared between security domains. The Secure and Non-secure SIO offer alternative views of the same GPIO registers, which are always mapped as GPIO function 5. However, the Non-secure SIO can only access pins which are enabled in the GPIO Non-secure mask configured by the ACCESSCTRL registers GPIO_NSMASK0 and GPIO_NSMASK1 . The layout of the NSMASK registers matches the layout of the SIO registers – for example, QSPI_SCK is bit 26 in both GPIO_HI_IN and GPIO_NSMASK1 .

When a pin is not enabled in Non-secure code:

• • Writes to the corresponding GPIO registers from a Non-secure context have no effect.
• • Reads from a Non-secure context return zeroes.
• • Reads and writes from a Secure context function as usual using the Secure bank.

The GPIO coprocessor port ( Section 3.6.1 ) provides dedicated instructions for accessing the SIO GPIO registers from the Cortex-M33 processors. This includes the ability to read and write 64 bits in a single operation.

3.1.4. Hardware spinlocks

The SIO provides 32 hardware spinlocks, which can be used to manage mutually-exclusive access to shared software resources. Each spinlock is a one-bit flag, mapped to a different address (from SPINLOCK0 to SPINLOCK31 ). Software interacts with each spinlock with one of the following operations:

• • Read: Attempt to claim the lock. Read value is non-zero if the lock was successfully claimed, or zero if the lock had already been claimed by a previous read.
• • Write (any value): Release the lock. The next attempt to claim the lock will succeed.

If both cores try to claim the same lock on the same clock cycle, core 0 succeeds.

Generally software will acquire a lock by repeatedly polling the lock bit ("spinning" on the lock) until it is successfully claimed. This is inefficient if the lock is held for long periods, so generally the spinlocks should be used to protect short critical sections of higher-level primitives such as mutexes, semaphores and queues.

For debugging purposes, the current state of all 32 spinlocks can be observed via SPINLOCK_ST .

RP2350 has separate spinlocks for Secure and Non-secure SIO banks because sharing these registers would allow Non-secure code to deliberately starve Secure code that attempts to acquire a lock. See Section 3.1.1 .

The processors on RP2350 support standard atomic/exclusive access instructions which, in concert with the global exclusive monitor ( Section 2.1.6 ), allow both cores to safely share variables in SRAM. The SIO spinlocks are still included for compatibility with RP2040.

Due to RP2350-E2 , writes to new SIO registers above an offset of +0x180 alias the spinlocks, causing spurious lock releases. The SDK by default uses atomic memory accesses to implement the hardware_sync_spin_lock API, as a workaround on RP2350 A2.

3.1.5. Inter-processor FIFOs (Mailboxes)

The SIO contains two FIFOs for passing data, messages or ordered events between the two cores. Each FIFO is 32 bits wide and four entries deep. One of the FIFOs can only be written by core 0 and read by core 1. The other can only be written by core 1 and read by core 0.

Each core writes to its outgoing FIFO by writing to FIFO_WR and reads from its incoming FIFO by reading from FIFO_RD . A status register, FIFO_ST , provides the following status signals:

• • Incoming FIFO contains data ( VLD ).
• • Outgoing FIFO has room for more data ( RDY ).
• • The incoming FIFO was read from while empty at some point in the past ( ROE ).
• • The outgoing FIFO was written to while full at some point in the past ( WOF ).

Writing to the outgoing FIFO while full, or reading from the incoming FIFO while empty, does not affect the FIFO state. The current contents and level of the FIFO is preserved. However, this does represent some loss of data or reception of invalid data by the software accessing the FIFO, so a sticky error flag is raised ( ROE or WOF ).

The SIO has a FIFO IRQ output for each core to notify the core that it has received FIFO data. This is a core-local interrupt , mapped to the same IRQ number on each core ( SIO_IRQ_FIFO , interrupt number 25). Non-secure FIFO interrupts use a separate interrupt line, ( SIO_IRQ_FIFO_NS , interrupt number 27). It is not possible to interrupt on the opposite core's FIFO.

Each IRQ output is the logical OR of the VLD , ROE and WOF bits in that core's FIFO_ST register: that is, the IRQ is asserted if any of these three bits is high, and clears again when they are all low. To clear the ROE and WOF flags, write any value to FIFO_ST . To clear the VLD flag, read data from the FIFO until it is empty.

If the corresponding interrupt line is enabled in the processor's interrupt controller, the processor takes an interrupt each time data appears in its FIFO, or if it has performed some invalid FIFO operation (read on empty, write on full).

ROE and WOF only become set if software misbehaves in some way. Generally, the interrupt handler triggers when data appears in the FIFO, raising the VLD flag. Then, the interrupt handler clears the IRQ by reading data from the FIFO until VLD goes low once more.

The inter-processor FIFOs and the Event signals are used by the bootrom ( Chapter 5 ) wait_for_vector routine, where core 1 remains in a sleep state until it is woken, and provided with its initial stack pointer, entry point and vector table through the FIFO.

RP2350 has separate FIFOs and interrupts for Secure and Non-secure SIO banks. See Section 3.1.1

3.1.6. Doorbells

The doorbell registers raise an interrupt on the opposite core. There are 8 doorbell flags in each direction, combined into a single doorbell interrupt per core. This is a core-local interrupt: the same interrupt number on each core ( SIO_IRQ_BELL , interrupt number 26) notifies that core of incoming doorbell interrupts.

Whereas the mailbox FIFOs are used for cross-core events whose count and order is important, doorbells are used for events which are accumulative (i.e. may post multiple times, but only answered once) and which can be responded to in any order.

Writing a non-zero value to the DOORBELL_OUT_SET register raises the opposite core's doorbell interrupt. The interrupt remains raised until all bits are cleared. Generally, the opposite core enters its doorbell interrupt handler, reads its DOORBELL_IN_CLR register to get the mask of active doorbell flags, and then writes back to acknowledge and clear the interrupt.

The DOORBELL_IN_SET register allows a processor to ring its own doorbell. This is useful when the routine which rings a doorbell can be scheduled on either core. Likewise, for symmetry, a processor can clear the opposite core's doorbell flags using the DOORBELL_OUT_CLR register: this is useful for setup code, but should be avoided in general because of the potential for race conditions when acknowledging interrupts meant for the opposite core.

At any time, a core can read back its DOORBELL_OUT_SET or DOORBELL_OUT_CLR register (they return the same result) to see the status of doorbell interrupts posted to the opposite core. Likewise, reading either DOORBELL_IN_SET or DOORBELL_IN_CLR returns the status of doorbell interrupts posted to this core.

i NOTE

RP2350 has separate per-core doorbell interrupt signals and doorbell registers for Secure and Non-secure SIO banks. Non-secure doorbells are posted on SIO_IRQ_BELL_NS , interrupt number 28. See Section 3.1.1 .

3.1.7. Integer divider

RP2040's memory-mapped integer divider peripheral is not present on RP2350, since the processors support divide instructions. The address space previously allocated for the divider registers is now reserved.

3.1.8. RISC-V platform timer

This 64-bit timer is a standard peripheral described in the RISC-V privileged specification, usable equally by the Arm and RISC-V processors on RP2350. It drives the per-core SIO_IRQ_MTIMECMP system-level interrupt ( Section 3.2 ), as well as the mip.mtip timer interrupt on the RISC-V processors.

There is a single 64-bit counter, shared between both cores. The low and high half can be accessed through the MTIME and MTIMEH SIO registers. Use the following procedure to safely read the 64-bit time using 32-bit register accesses:

1. 1. Read the upper half, MTIMEH .
2. 2. Read the lower half, MTIME .
3. 3. Read the upper half again.
4. 4. Loop if the two upper-half reads returned different values.

This is similar to the procedure for reading RP2350 system timers ( Section 12.8 ). The loop should only happen once, when the timer is read at exactly the instant of a 32-bit rollover, and even this is only occasional. If you require constant-time operation, you can instead zero the lower half when the two upper-half reads differ.

Timer interrupts are generated based on a per-core 64-bit time comparison value, accessed through the MTIMECMP and MTIMECMPH SIO registers. Each core gets its own copy of these registers, accessed at the same address. The per-core interrupt is asserted whenever the current time indicated in the MTIME registers is greater than or equal to that core's MTIMECMP . Use the following sequence to write a new 64-bit timer comparison value without causing spurious interrupts:

1. 1. Write all-ones to MTIMECMP (guaranteed greater than or equal to the old value, and the lower half of the target value).
2. 2. Write the upper half of the target value to MTIMECMPH (combined 64-bit value is still greater than or equal to the target value).

1. 3. Write the lower half of the target value to MTIMECMP .

The RISC-V timer can count either ticks from the system-level tick generator ( Section 8.5 ), or system clock cycles, selected by the MTIME_CTRL register. Use a 1 microsecond time base for compatibility with most RISC-V software.

3.1.9. TMDS encoder

Each core is equipped with an implementation of the TMDS encode algorithm described in chapter 3 of the DVI 1.0 specification. In general, the HSTX peripheral ( Section 12.11 ) supports lower processor overhead for DVI-D output as well as a wider range of pixel formats, but the SIO TMDS encoders are included for use with non-HSTX-capable GPIOs.

The TMDS_CTRL register allows configuration of a number of input pixel formats, from 16-bit RGB down to 1-bit monochrome. Once the encoder has been set up, the processor writes 32 bits of colour data at a time to TMDS_WDATA , and then reads TMDS data symbols from the output registers. Depending on the pixel format, there may be multiple TMDS symbols read for each write to TMDS_WDATA . There are no stalls: encoding is limited entirely by the processor's load/store bandwidth, up to one 32-bit read or write per cycle per core.

To allow for framebuffer/scanbuffer resolution lower than the display resolution, the output registers have both peek and pop aliases (e.g. TMDS_PEEK_SINGLE and TMDS_POP_SINGLE ). Reading either register advances the encoder's DC balance counter, but only the pop alias shifts the colour data in TMDS_WDATA so that multiple correctly-DC-balanced TMDS symbols can be generated from the same input pixel.

The TMDS encoder peripherals are not duplicated over security domains. They are assigned to the Secure SIO at reset, and can be reassigned to the Non-secure SIO using the PERL_NONSEC register.

3.1.10. Interpolator

Each core is equipped with two interpolators ( INTERP0 and INTERP1 ) that can accelerate tasks by combining certain pre-configured operations into a single processor cycle. Intended for cases where the pre-configured operation repeats many times, interpolators result in code which uses both fewer CPU cycles and fewer CPU registers in time-critical sections.

The interpolators already accelerate audio operations within the SDK. Their flexible configuration makes it possible to optimise many other tasks, including:

• • quantization
• • dithering
• • table lookup address generation
• • affine texture mapping
• • decompression
• • linear feedback

Figure 8. An interpolator. The two accumulator registers and three base registers have single-cycle read/write access from the processor. The interpolator is organised into two lanes, which perform masking, shifting and sign-extension operations on the two accumulators. This produces three possible results, by adding the intermediate shift/mask values to the three base registers. From left to right, the multiplexers on each lane are controlled by the following flags in the CTRL registers: CROSS_RESULT , CROSS_INPUT , SIGNED , and ADD_RAW .

The processor can write or read any interpolator register in one cycle, and the results are ready on the next cycle. The processor can also perform an addition on one of the two accumulators ACCUM0 or ACCUM1 by writing to the corresponding ACCUMx_ADD register.

The three results are available in the read-only locations PEEK0 , PEEK1 , PEEK2 . Reading from these locations does not change the state of the interpolator. The results are also aliased at the locations POP0 , POP1 , POP2 ; reading from a POPx alias returns the same result as the corresponding PEEKx , and simultaneously writes back the lane results to the accumulators. Use the POPx aliases to advance the state of interpolator each time a result is read.

You can adjust interpolator behaviour with the following operational modes:

• • fractional blending between two values
• • clamping values to restrict them within a given range.

The following example shows a trivial example of popping a lane result to produce simple iterative feedback.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 11 - 23

11 void times_table() {
12     puts("9 times table:");
13
14     // Initialise lane 0 on interp0 on this core
15     interp_config cfg = interp_default_config();
16     interp_set_config(interp0, 0, &cfg);
17
18     interp0->accum[0] = 0;
19     interp0->base[0] = 9;
20
21     for (int i = 0; i < 10; ++i)
22         printf("%d\n", interp0->pop[0]);
23 }

3.1.10.1. Lane operations

Figure 9. Each lane of each interpolator can be configured to perform mask, shift and sign-extension on one of the accumulators. This is fed into adders which produce final results, which may optionally be fed back into the accumulators with each read. The datapath can be configured using a handful of 32-bit multiplexers. From left to right, these are controlled by the following CTRL flags: CROSS_RESULT, CROSS_INPUT, SIGNED, and ADD_RAW.

Each lane performs these three operations, in sequence:

• • A right shift by CTRL_LANE x _SHIFT (0 to 31 bits)
• • A mask of bits from CTRL_LANE x _MASK_LSB to CTRL_LANE x _MASK_MSB inclusive (each ranging from bit 0 to bit 31)
• • A sign extension from the top of the mask, i.e. take bit CTRL_LANE x _MASK_MSB and OR it into all more-significant bits, if CTRL_LANE x _SIGNED is set

For example, if:

• • ACCUM0 = 0xdeadbeef
• • CTRL_LANE0_SHIFT = 8
• • CTRL_LANE0_MASK_LSB = 4
• • CTRL_LANE0_MASK_MSB = 7
• • CTRL_SIGNED = 1

Then lane 0 would produce the following results at each stage:

• • Right shift by 8 to produce 0x00deadbe
• • Mask bits 7 to 4 to produce 0x00deadbe & 0x000000f0 = 0x000000b0
• • Sign-extend up from bit 7 to produce 0xffffffb0

In software:

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 25 - 46

25 void moving_mask() {
26     interp_config cfg = interp_default_config();
27     interp0->accum[0] = 0x1234abcd;
28
29     puts("Masking:");
30     printf("ACCUM0 = %08x\n", interp0->accum[0]);
31     for (int i = 0; i < 8; ++i) {
32         // LSB, then MSB. These are inclusive, so 0,31 means "the entire 32 bit register"
33         interp_config_set_mask(&cfg, i * 4, i * 4 + 3);
34         interp_set_config(interp0, 0, &cfg);
35         // Reading from ACCUMx_ADD returns the raw lane shift and mask value, without BASEx
36         printf("Nibble %d: %08x\n", i, interp0->add_raw[0]);
37     }
38
39     puts("Masking with sign extension:");
40     interp_config_set_signed(&cfg, true);
41     for (int i = 0; i < 8; ++i) {
42         interp_config_set_mask(&cfg, i * 4, i * 4 + 3);
43         interp_set_config(interp0, 0, &cfg);
44         printf("Nibble %d: %08x\n", i, interp0->add_raw[0]);
45     }
46 }

The above example should print the following:

ACCUM0 = 1234abcd
Nibble 0: 0000000d
Nibble 1: 000000c0
Nibble 2: 00000b00
Nibble 3: 0000a000
Nibble 4: 00040000
Nibble 5: 00300000
Nibble 6: 02000000
Nibble 7: 10000000
Masking with sign extension:
Nibble 0: ffffffff
Nibble 1: fffffffc
Nibble 2: fffffb00
Nibble 3: ffffa000
Nibble 4: 00040000
Nibble 5: 00300000
Nibble 6: 02000000
Nibble 7: 10000000

Changing the result and input multiplexers can create feedback between the accumulators. This is useful for audio dithering.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 48 - 66

48 void cross_lanes() {
49     interp_config cfg = interp_default_config();
50     interp_config_set_cross_result(&cfg, true);
51     // ACCUM0 gets lane 1 result:
52     interp_set_config(interp0, 0, &cfg);
53     // ACCUM1 gets lane 0 result:
54     interp_set_config(interp0, 1, &cfg);
55
56     interp0->accum[0] = 123;
57     interp0->accum[1] = 456;
58     interp0->base[0] = 1;
59     interp0->base[1] = 0;
60     puts("Lane result crossover:");
61     for (int i = 0; i < 10; ++i) {
62         uint32_t peek0 = interp0->peek[0];
63         uint32_t pop1 = interp0->pop[1];
64         printf("PEEK0, POP1: %d, %d\n", peek0, pop1);
65     }
66 }

This should print the following :

PEEK0, POP1: 124, 456
PEEK0, POP1: 457, 124
PEEK0, POP1: 125, 457
PEEK0, POP1: 458, 125
PEEK0, POP1: 126, 458
PEEK0, POP1: 459, 126
PEEK0, POP1: 127, 459
PEEK0, POP1: 460, 127
PEEK0, POP1: 128, 460
PEEK0, POP1: 461, 128

3.1.10.2. Blend mode

Blend mode is available on INTERP0 on each core, and is enabled by the CTRL_LANE0_BLEND control flag. It performs linear interpolation, which we define as follows:

Where \( x_0 \) is the register BASE0 , \( x_1 \) is the register BASE1 , and \( \alpha \) is a fractional value formed from the least significant 8 bits of the lane 1 shift and mask value.

Blend mode differs from normal mode in the following ways:

• • PEEK0, POP0 return the 8-bit alpha value (the 8 LSBs of the lane 1 shift and mask value), with zeroes in result bits 31 down to 24.
• • PEEK1, POP1 return the linear interpolation between BASE0 and BASE1
• • PEEK2, POP2 do not include lane 1 result in the addition (i.e. it is BASE2 + lane 0 shift and mask value)

The result of the linear interpolation is equal to BASE0 when the alpha value is 0, and equal to BASE0 + 255/256 * ( BASE1 - BASE0 ) when the alpha value is all-ones.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 68 - 87

68 void simple_blend1() {
69     puts("Simple blend 1:");
70
71     interp_config cfg = interp_default_config();
72     interp_config_set_blend(&cfg, true);
73     interp_set_config(interp0, 0, &cfg);
74
75     cfg = interp_default_config();
76     interp_set_config(interp0, 1, &cfg);
77
78     interp0->base[0] = 500;
79     interp0->base[1] = 1000;
80
81     for (int i = 0; i <= 6; i++) {
82         // set fraction to value between 0 and 255
83         interp0->accum[1] = 255 * i / 6;
84         // ≈ 500 + (1000 - 500) * i / 6;
85         printf("%d\n", (int) interp0->peek[1]);
86     }
87 }

This should print the following (note the 255/256 resulting in 998 not 1000):

500
582
666
748
832
914
998

CTRL_LANE1_SIGNED controls whether BASE0 and BASE1 are sign-extended for this interpolation (this sign extension is required because the interpolation produces an intermediate product value 40 bits in size). CTRL_LANE0_SIGNED continues to control the sign extension of the lane 0 intermediate result in PEEK2, POP2 as normal.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 90 - 121

90 void print_simple_blend2_results(bool is_signed) {
91     // lane 1 signed flag controls whether base 0/1 are treated as signed or unsigned
92     interp_config cfg = interp_default_config();
93     interp_config_set_signed(&cfg, is_signed);
94     interp_set_config(interp0, 1, &cfg);
95
96     for (int i = 0; i <= 6; i++) {
97         interp0->accum[1] = 255 * i / 6;
98         if (is_signed) {
99             printf("%d\n", (int) interp0->peek[1]);
100         } else {
101             printf("0x%08x\n", (uint) interp0->peek[1]);
102         }
103     }
104 }
105
106 void simple_blend2() {
107     puts("Simple blend 2:");
108
109     interp_config cfg = interp_default_config();
110     interp_config_set_blend(&cfg, true);
111     interp_set_config(interp0, 0, &cfg);
112
113     interp0->base[0] = (uint32_t) -1000;
114     interp0->base[1] = 1000;
115
116     puts("signed:");
117     print_simple_blend2_results(true);
118
119     puts("unsigned:");
120     print_simple_blend2_results(false);
121 }

This should print the following:

signed:
-1000
-672
-336
-8
328
656
992
unsigned:
0xfffffc18
0xd5fffd60
0xaaffffeb0
0x80fffff8
0x56000148
0x2c000290
0x010003e0

Finally, in blend mode when using the BASE_1AND0 register to send a 16-bit value to each of BASE0 and BASE1 with a single 32-bit write, the sign-extension of these 16-bit values to full 32-bit values during the write is controlled by CTRL_LANE1_SIGNED for both bases, as opposed to non-blend-mode operation, where CTRL_LANE0_SIGNED affects extension into BASE0 and CTRL_LANE1_SIGNED affects extension into BASE1 .

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 124 - 145

124 void simple_blend3() {
125     puts("Simple blend 3:");
126
127     interp_config cfg = interp_default_config();
128     interp_config_set_blend(&cfg, true);
129     interp_set_config(interp0, 0, &cfg);
130
131     cfg = interp_default_config();
132     interp_set_config(interp0, 1, &cfg);
133
134     interp0->accum[1] = 128;
135     interp0->base01 = 0x30005000;
136     printf("0x%08x\n", (int) interp0->peek[1]);
137     interp0->base01 = 0xe000f000;
138     printf("0x%08x\n", (int) interp0->peek[1]);
139
140     interp_config_set_signed(&cfg, true);
141     interp_set_config(interp0, 1, &cfg);
142
143     interp0->base01 = 0xe000f000;
144     printf("0x%08x\n", (int) interp0->peek[1]);
145 }

This should print the following:

0x00004000
0x0000e800
0xffffe800

3.1.10.3. Clamp Mode

Clamp mode is available on INTERP1 on each core. To enable clamp mode, set the CTRL_LANE0_CLAMP control flag to high. In clamp mode, the PEEK0/POP0 result is the lane value (shifted, masked, sign-extended ACCUM0 ) clamped between BASE0 and BASE1 . In other words, if the lane value is less than BASE0 , a value of BASE0 is produced; if greater than BASE1 , a value of BASE1 is produced; otherwise, the value passes through. No addition is performed. The signedness of these comparisons is controlled by the CTRL_LANE0_SIGNED flag.

Other than this, the interpolator behaves the same as in normal mode.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 193 - 211

193 void clamp() {
194     puts("Clamp:");
195     interp_config cfg = interp_default_config();
196     interp_config_set_clamp(&cfg, true);
197     interp_config_set_shift(&cfg, 2);
198     // set mask according to new position of sign bit..
199     interp_config_set_mask(&cfg, 0, 29);
200     // ...so that the shifted value is correctly sign extended
201     interp_config_set_signed(&cfg, true);
202     interp_set_config(interp1, 0, &cfg);
203
204     interp1->base[0] = 0;
205     interp1->base[1] = 255;
206
207     for (int i = -1024; i <= 1024; i += 256) {

208     interp1->accum[0] = i;
209     printf("%d\t%d\n", i, (int) interp1->peek[0]);
210 }
211 }

This should print the following:

-1024  0
-768   0
-512   0
-256   0
0       0
256    64
512    128
768    192
1024   255

3.1.10.4. Sample use case: linear interpolation

Linear interpolation combines blend mode with other interpolator functionality. In this example, ACCUM0 tracks a fixed-point (integer/fraction) position within a list of values to be interpolated. Lane 0 is used to produce an address into the value array for the integer part of the position. The fractional part of the position is shifted to produce a value from 0-255 for the blend. The blend is performed between two consecutive values in the array.

Finally the fractional position is updated via a single write to ACCUM0_ADD_RAW .

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 147 - 191

147 void linear_interpolation() {
148     puts("Linear interpolation:");
149     const int uv_fractional_bits = 12;
150
151     // for lane 0
152     // shift and mask XXXX XXXX XXXX XXXX XXXX FFFF FFFF FFFF (accum 0)
153     // to          0000 0000 000X XXXX XXXX XXXX XXXX XXX0
154     // i.e. non fractional part times 2 (for uint16_t)
155     interp_config cfg = interp_default_config();
156     interp_config_set_shift(&cfg, uv_fractional_bits - 1);
157     interp_config_set_mask(&cfg, 1, 32 - uv_fractional_bits);
158     interp_config_set_blend(&cfg, true);
159     interp_set_config(interp0, 0, &cfg);
160
161     // for lane 1
162     // shift XXXX XXXX XXXX XXXX XXXX FFFF FFFF FFFF (accum 0 via cross input)
163     // to      0000 XXXX XXXX XXXX XXXX FFFF FFFF FFFF
164
165     cfg = interp_default_config();
166     interp_config_set_shift(&cfg, uv_fractional_bits - 8);
167     interp_config_set_signed(&cfg, true);
168     interp_config_set_cross_input(&cfg, true); // signed blending
169     interp_set_config(interp0, 1, &cfg);
170
171     int16_t samples[] = {0, 10, -20, -1000, 500};
172
173     // step is 1/4 in our fractional representation
174     uint step = (1 << uv_fractional_bits) / 4;
175
176     interp0->accum[0] = 0; // initial sample_offset;

177     interp0->base[2] = (uintptr_t) samples;
178     for (int i = 0; i < 16; i++) {
179         // result2 = samples + (lane0 raw result)
180         // i.e. ptr to the first of two samples to blend between
181         int16_t *sample_pair = (int16_t *) interp0->peek[2];
182         interp0->base[0] = sample_pair[0];
183         interp0->base[1] = sample_pair[1];
184         uint32_t peek1 = interp0->peek[1];
185         uint32_t add_raw1 = interp0->add_raw[1];
186         printf("%d\t(%d%% between %d and %d)\n", (int) peek1,
187             100 * (add_raw1 & 0xff) / 0xff,
188             sample_pair[0], sample_pair[1]);
189         interp0->add_raw[0] = step;
190     }
191 }

This should print the following:

0      (0% between 0 and 10)
2      (25% between 0 and 10)
5      (50% between 0 and 10)
7      (75% between 0 and 10)
10     (0% between 10 and -20)
2      (25% between 10 and -20)
-5     (50% between 10 and -20)
-13    (75% between 10 and -20)
-20    (0% between -20 and -1000)
-265   (25% between -20 and -1000)
-510   (50% between -20 and -1000)
-755   (75% between -20 and -1000)
-1000  (0% between -1000 and 500)
-625   (25% between -1000 and 500)
-250   (50% between -1000 and 500)
125    (75% between -1000 and 500)

This method is used for fast approximate audio upscaling in the SDK.

3.1.10.5. Sample use case: simple affine texture mapping

Simple affine texture mapping can be implemented by using fixed-point arithmetic for texture coordinates, and stepping a fixed amount in each coordinate for every pixel in a scanline. The integer parts of the texture coordinates form an address into the texture. Reading from POP2 adds the offset to the texture base pointer. The processor loads the resulting address to sample a pixel colour from the texture.

By using two lanes, all three base values, and the CTRL_LANE x _ADD_RAW flag, you can use the interpolator to reduce an expensive CPU operation to a single cycle iteration.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/interp/hello_interp/hello_interp.c Lines 214 - 272

214 void texture_mapping_setup(uint8_t *texture, uint texture_width_bits, uint
    texture_height_bits,
215                             uint uv_fractional_bits) {
216     interp_config cfg = interp_default_config();
217     // set add_raw flag to use raw (un-shifted and un-masked) lane accumulator value when
    adding
218     // it to the lane base to make the lane result
219     interp_config_set_add_raw(&cfg, true);
220     interp_config_set_shift(&cfg, uv_fractional_bits);

221     interp_config_set_mask(&cfg, 0, texture_width_bits - 1);
222     interp_set_config(interp0, 0, &cfg);
223
224     interp_config_set_shift(&cfg, uv_fractional_bits - texture_width_bits);
225     interp_config_set_mask(&cfg, texture_width_bits, texture_width_bits +
texture_height_bits - 1);
226     interp_set_config(interp0, 1, &cfg);
227
228     interp0->base[2] = (uintptr_t) texture;
229 }
230
231 void texture_mapped_span(uint8_t *output, uint32_t u, uint32_t v, uint32_t du, uint32_t dv,
uint count) {
232     // u, v are texture coordinates in fixed point with uv_fractional_bits fractional bits
233     // du, dv are texture coordinate steps across the span in same fixed point.
234     interp0->accum[0] = u;
235     interp0->base[0] = du;
236     interp0->accum[1] = v;
237     interp0->base[1] = dv;
238     for (uint i = 0; i < count; i++) {
239         // equivalent to
240         // uint32_t sm_result0 = (accum0 >> uv_fractional_bits) & (1 << (texture_width_bits -
1);
241         // uint32_t sm_result1 = (accum1 >> uv_fractional_bits) & (1 << (texture_height_bits -
1);
242         // uint8_t *address = texture + sm_result0 + (sm_result1 << texture_width_bits);
243         // output[i] = *address;
244         // accum0 = du + accum0;
245         // accum1 = dv + accum1;
246
247         // result2 is the texture address for the current pixel;
248         // popping the result advances to the next iteration
249         output[i] = *(uint8_t *) interp0->pop[2];
250     }
251 }
252
253 void texture_mapping() {
254     puts("Affine Texture mapping (with texture wrap):");
255
256     uint8_t texture[] = {
257         0x00, 0x01, 0x02, 0x03,
258         0x10, 0x11, 0x12, 0x13,
259         0x20, 0x21, 0x22, 0x23,
260         0x30, 0x31, 0x32, 0x33,
261     };
262     // 4x4 texture
263     texture_mapping_setup(texture, 2, 2, 16);
264     uint8_t output[12];
265     uint32_t du = 65536 / 2; // step of 1/2
266     uint32_t dv = 65536 / 3; // step of 1/3
267     texture_mapped_span(output, 0, 0, du, dv, 12);
268
269     for (uint i = 0; i < 12; i++) {
270         printf("0x%02x\n", output[i]);
271     }
272 }

This should print the following:

0x00
0x00
0x01
0x01
0x12
0x12
0x13
0x23
0x20
0x20
0x31
0x31

3.1.11. List of registers

The SIO registers start at a base address of 0xd000000 (defined as SIO_BASE in SDK).

Table 17. List of SIO registers

SIO: CPUID Register

Offset: 0x000

Description

Processor core identifier

Table 18. CPUID Register

SIO: GPIO_IN Register

Offset: 0x004

Table 19. GPIO_IN Register

SIO: GPIO_HI_IN Register

Offset: 0x008

Description

Input value on GPIO32...47, QSPI IOs and USB pins

In the Non-secure SIO, Secure-only GPIOs (as per ACCESSCTRL) appear as zero.

Table 20. GPIO_HI_IN Register

SIO: GPIO_OUT Register

Offset: 0x010

Description

GPIO0...31 output value

Table 21. GPIO_OUT Register

SIO: GPIO_HI_OUT Register

Offset: 0x014

Description

Output value for GPIO32...47, QSPI IOs and USB pins.

Write to set output level (1/0 → high/low). Reading back gives the last value written, NOT the input value from the pins. If core 0 and core 1 both write to GPIO_HI_OUT simultaneously (or to a SET/CLR/XOR alias), the result is as though the write from core 0 took place first, and the write from core 1 was then applied to that intermediate result.

In the Non-secure SIO, Secure-only GPIOs (as per ACCESSCTRL) ignore writes, and their output status reads back as zero. This is also true for SET/CLR/XOR aliases of this register.

Table 22. GPIO_HI_OUT Register

SIO: GPIO_OUT_SET Register

Offset: 0x018

Description

GPIO0...31 output value set

Table 23. GPIO_OUT_SET Register

SIO: GPIO_HI_OUT_SET Register

Offset: 0x01c

Description

Output value set for GPIO32..47, QSPI IOs and USB pins.

Perform an atomic bit-set on GPIO_HI_OUT, i.e. GPIO_HI_OUT |= wdata

Table 24.
GPIO_HI_OUT_SET
Register

SIO: GPIO_OUT_CLR Register

Offset: 0x020

Description

GPIO0...31 output value clear

Table 25.
GPIO_OUT_CLR
Register

SIO: GPIO_HI_OUT_CLR Register

Offset: 0x024

Description

Output value clear for GPIO32..47, QSPI IOs and USB pins.

Perform an atomic bit-clear on GPIO_HI_OUT, i.e. GPIO_HI_OUT &= ~wdata

Table 26.
GPIO_HI_OUT_CLR
Register

SIO: GPIO_OUT_XOR Register

Offset: 0x028

Description

GPIO0...31 output value XOR

Table 27.
GPIO_OUT_XOR
Register

SIO: GPIO_HI_OUT_XOR Register

Offset: 0x02c

Description

Output value XOR for GPIO32..47, QSPI IOs and USB pins.
Perform an atomic bitwise XOR on GPIO_HI_OUT, i.e. GPIO_HI_OUT ^= wdata

Table 28.
GPIO_HI_OUT_XOR
Register

SIO: GPIO_OE Register

Offset: 0x030

Description

GPIO0...31 output enable

Table 29. GPIO_OE
Register

SIO: GPIO_HI_OE Register

Offset: 0x034

Description

Output enable value for GPIO32...47, QSPI IOs and USB pins.

Write output enable (1/0 → output/input). Reading back gives the last value written. If core 0 and core 1 both write to GPIO_HI_OE simultaneously (or to a SET/CLR/XOR alias), the result is as though the write from core 0 took place first, and the write from core 1 was then applied to that intermediate result.

In the Non-secure SIO, Secure-only GPIOs (as per ACCESSCTRL) ignore writes, and their output status reads back as zero. This is also true for SET/CLR/XOR aliases of this register.

Table 30. GPIO_HI_OE
Register

SIO: GPIO_OE_SET Register

Offset: 0x038

Description

GPIO0...31 output enable set

Table 31.
GPIO_OE_SET Register

SIO: GPIO_HI_OE_SET Register

Offset: 0x03c

Description

Output enable set for GPIO32...47, QSPI IOs and USB pins.

Perform an atomic bit-set on GPIO_HI_OE, i.e. GPIO_HI_OE |= wdata

Table 32.
GPIO_HI_OE_SET Register

SIO: GPIO_OE_CLR Register

Offset: 0x040

Description

GPIO0...31 output enable clear

Table 33.
GPIO_OE_CLR Register

SIO: GPIO_HI_OE_CLR Register

Offset: 0x044

Description

Output enable clear for GPIO32...47, QSPI IOs and USB pins.

Perform an atomic bit-clear on GPIO_HI_OE, i.e. GPIO_HI_OE &= ~wdata

Table 34.
GPIO_HI_OE_CLR
Register

SIO: GPIO_OE_XOR Register

Offset: 0x048

Description

GPIO0...31 output enable XOR

Table 35.
GPIO_OE_XOR
Register

SIO: GPIO_HI_OE_XOR Register

Offset: 0x04c

Description

Output enable XOR for GPIO32...47, QSPI IOs and USB pins.

Perform an atomic bitwise XOR on GPIO_HI_OE, i.e. \( \text{GPIO\_HI\_OE} \wedge= \text{wdata} \)

Table 36.
GPIO_HI_OE_XOR
Register

SIO: FIFO_ST Register

Offset: 0x050

Description

Status register for inter-core FIFOs (mailboxes).

There is one FIFO in the core 0 → core 1 direction, and one core 1 → core 0. Both are 32 bits wide and 8 words deep.

Core 0 can see the read side of the 1 → 0 FIFO (RX), and the write side of 0 → 1 FIFO (TX).

Core 1 can see the read side of the 0 → 1 FIFO (RX), and the write side of 1 → 0 FIFO (TX).

The SIO IRQ for each core is the logical OR of the VLD, WOF and ROE fields of its FIFO_ST register.

Table 37. FIFO_ST Register

SIO: FIFO_WR Register

Offset: 0x054

Table 38. FIFO_WR Register

SIO: FIFO_RD Register

Offset: 0x058

Table 39. FIFO_RD Register

SIO: SPINLOCK_ST Register

Offset: 0x05c

Table 40. SPINLOCK_ST Register

SIO: INTERP0_ACCUM0 Register

Offset: 0x080

Table 41. INTERP0_ACCUM0 Register

SIO: INTERP0_ACCUM1 Register

Offset: 0x084

Table 42. INTERP0_ACCUM1 Register

SIO: INTERP0_BASE0 Register

Offset: 0x088

Table 43.
INTERP0_BASE0
Register

SIO: INTERP0_BASE1 Register

Offset: 0x08c

Table 44.
INTERP0_BASE1
Register

SIO: INTERP0_BASE2 Register

Offset: 0x090

Table 45.
INTERP0_BASE2
Register

SIO: INTERP0_POP_LANE0 Register

Offset: 0x094

Table 46.
INTERP0_POP_LANE0
Register

SIO: INTERP0_POP_LANE1 Register

Offset: 0x098

Table 47.
INTERP0_POP_LANE1
Register

SIO: INTERP0_POP_FULL Register

Offset: 0x09c

Table 48.
INTERP0_POP_FULL
Register

SIO: INTERP0_PEEK_LANE0 Register

Offset: 0x0a0

Table 49.
INTERP0_PEEK_LANE
0 Register

SIO: INTERP0_PEEK_LANE1 Register

Offset: 0x0a4

Table 50.
INTERP0_PEEK_LANE
1 Register

SIO: INTERP0_PEEK_FULL Register

Offset: 0x0a8

Table 51.
INTERP0_PEEK_FULL
Register

SIO: INTERP0_CTRL_LANE0 Register

Offset: 0x0ac

Description

Control register for lane 0

Table 52.
INTERP0_CTRL_LANE
0 Register

SIO: INTERP0_CTRL_LANE1 Register

Offset: 0x0b0

Description

Control register for lane 1

Table 53.
INTERP0_CTRL_LANE
1 Register

SIO: INTERP0_ACCUM0_ADD Register

Offset: 0x0b4

Table 54.
INTERP0_ACCUM0_ADD
Register

SIO: INTERP0_ACCUM1_ADD Register

Offset: 0x0b8

Table 55.
INTERP0_ACCUM1_ADD
Register

SIO: INTERP0_BASE_1AND0 Register

Offset: 0x0bc

Table 56.
INTERP0_BASE_1AND
0 Register

SIO: INTERP1_ACCUM0 Register

Offset: 0x0c0

Table 57.
INTERP1_ACCUM0
Register

SIO: INTERP1_ACCUM1 Register

Offset: 0x0c4

Table 58.
INTERP1_ACCUM1
Register

SIO: INTERP1_BASE0 Register

Offset: 0x0c8

Table 59.
INTERP1_BASE0
Register

SIO: INTERP1_BASE1 Register

Offset: 0x0cc

Table 60.
INTERP1_BASE1
Register

SIO: INTERP1_BASE2 Register

Offset: 0x0d0

Table 61.
INTERP1_BASE2
Register

SIO: INTERP1_POP_LANE0 Register

Offset: 0x0d4

Table 62.
INTERP1_POP_LANE0
Register

SIO: INTERP1_POP_LANE1 Register

Offset: 0x0d8

Table 63.
INTERP1_POP_LANE1
Register

SIO: INTERP1_POP_FULL Register

Offset: 0x0dc

Table 64.
INTERP1_POP_FULL
Register

SIO: INTERP1_PEEK_LANE0 Register

Offset: 0x0e0

Table 65.
INTERP1_PEEK_LANE
0 Register

SIO: INTERP1_PEEK_LANE1 Register

Offset: 0x0e4

Table 66.
INTERP1_PEEK_LANE
1 Register

SIO: INTERP1_PEEK_FULL Register

Offset: 0x0e8

Table 67.
INTERP1_PEEK_FULL
Register

SIO: INTERP1_CTRL_LANE0 Register

Offset: 0x0ec

Description

Control register for lane 0

Table 68.
INTERP1_CTRL_LANE
0 Register

SIO: INTERP1_CTRL_LANE1 Register

Offset: 0x0f0

Description

Control register for lane 1

Table 69.
INTERP1_CTRL_LANE
1 Register

SIO: INTERP1_ACCUM0_ADD Register

Offset: 0x0f4

Table 70.
INTERP1_ACCUM0_ADD
Register

SIO: INTERP1_ACCUM1_ADD Register

Offset: 0x0f8

Table 71.
INTERP1_ACCUM1_ADD
Register

SIO: INTERP1_BASE_1AND0 Register

Offset: 0x0fc

Table 72.
INTERP1_BASE_1AND
0 Register

SIO: SPINLOCK0, SPINLOCK1, ..., SPINLOCK30, SPINLOCK31 Registers

Offsets: 0x100, 0x104, ..., 0x178, 0x17c

Table 73. SPINLOCK0,
SPINLOCK1, ...,
SPINLOCK30,
SPINLOCK31
Registers

SIO: DOORBELL_OUT_SET Register

Offset: 0x180

Table 74.
DOORBELL_OUT_SET
Register

SIO: DOORBELL_OUT_CLR Register

Offset: 0x184

Table 75.
DOORBELL_OUT_CLR
Register

SIO: DOORBELL_IN_SET Register

Offset: 0x188

Table 76.
DOORBELL_IN_SET
Register

SIO: DOORBELL_IN_CLR Register

Offset: 0x18c

Table 77.
DOORBELL_IN_CLR
Register

SIO: PERI_NONSEC Register

Offset: 0x190

Description

Detach certain core-local peripherals from Secure SIO, and attach them to Non-secure SIO, so that Non-secure software can use them. Attempting to access one of these peripherals from the Secure SIO when it is attached to the Non-secure SIO, or vice versa, will generate a bus error.

This register is per-core, and is only present on the Secure SIO.

Most SIO hardware is duplicated across the Secure and Non-secure SIO, so is not listed in this register.

Table 78.
PERI_NONSEC
Register

SIO: RISC_V_SOFTIRQ Register

Offset: 0x1a0

Description

Control the assertion of the standard software interrupt (MIP.MSIP) on the RISC-V cores.

Unlike the RISC-V timer, this interrupt is not routed to a normal system-level interrupt line, so can not be used by the Arm cores.

It is safe for both cores to write to this register on the same cycle. The set/clear effect is accumulated across both cores, and then applied. If a flag is both set and cleared on the same cycle, only the set takes effect.

Table 79.
RISC_V_SOFTIRQ
Register

SIO: MTIME_CTRL Register

Offset: 0x1a4

Description

Control register for the RISC-V 64-bit Machine-mode timer. This timer is only present in the Secure SIO, so is only accessible to an Arm core in Secure mode or a RISC-V core in Machine mode.

Note whilst this timer follows the RISC-V privileged specification, it is equally usable by the Arm cores. The interrupts are routed to normal system-level interrupt lines as well as to the MIP.MTIP inputs on the RISC-V cores.

Table 80.
MTIME_CTRL Register

SIO: MTIME Register

Offset: 0x1b0

Table 81. MTIME Register

SIO: MTIMEH Register

Offset: 0x1b4

Table 82. MTIMEH Register

SIO: MTIMECMP Register

Offset: 0x1b8

Table 83. MTIMECMP Register

SIO: MTIMECMPH Register

Offset: 0x1bc

Table 84. MTIMECMPH Register

SIO: TMDS_CTRL Register

Offset: 0x1c0

Description

Control register for TMDS encoder.

Table 85. TMDS_CTRL Register

SIO: TMDS_WDATA Register

Offset: 0x1c4

Table 86.
TMDS_WDATA
Register

SIO: TMDS_PEEK_SINGLE Register

Offset: 0x1c8

Table 87.
TMDS_PEEK_SINGLE
Register

SIO: TMDS_POP_SINGLE Register

Offset: 0x1cc

Table 88.
TMDS_POP_SINGLE
Register

SIO: TMDS_PEEK_DOUBLE_L0 Register

Offset: 0x1d0

Table 89.
TMDS_PEEK_DOUBLE_
L0 Register

SIO: TMDS_POP_DOUBLE_L0 Register

Offset: 0x1d4

Table 90.
TMDS_POP_DOUBLE_
L0 Register

SIO: TMDS_PEEK_DOUBLE_L1 Register

Offset: 0x1d8

Table 91.
TMDS_PEEK_DOUBLE_
L1 Register

SIO: TMDS_POP_DOUBLE_L1 Register

Offset: 0x1dc

Table 92.
TMDS_POP_DOUBLE_L
1 Register

SIO: TMDS_PEEK_DOUBLE_L2 Register

Offset: 0x1e0

Table 93.
TMDS_PEEK_DOUBLE_L
2 Register

SIO: TMDS_POP_DOUBLE_L2 Register

Offset: 0x1e4

Table 94.
TMDS_POP_DOUBLE_L
2 Register

3.2. Interrupts

Each core is equipped with an internal interrupt controller, with 52 interrupt inputs. For the most part each core has exactly the same interrupts routed to it, though there are some exceptions, referred to as core-local interrupts , where there is an individual per-core interrupt source mapped to the same interrupt number on each core:

• • Cross-core FIFO interrupts: SIO_IRQ_FIFO and SIO_IRQ_FIFO_NS ( Section 3.1.5 )
• • Cross-core doorbell interrupts: SIO_IRQ_BELL and SIO_IRQ_BELL_NS ( Section 3.1.6 )
• • RISC-V platform timer (also usable by Arm cores): SIO_IRQ_MTIMECMP ( Section 3.1.8 )
• • GPIO interrupts: IO_IRQ_BANK0 , IRQ_IO_BANK0_NS , IO_IRQ_QSPI , IO_IRQ_QSPI_NS ( Section 9.5 )

The remaining interrupt inputs have the same interrupt source mirrored identically on both cores. Non-core-local interrupts should only be enabled in the interrupt controller of a single core at a time, and will be serviced by the core whose interrupt controller they are enabled in.

Table 95. System-level
interrupt numbering.
All interrupts are
routed to both
processors.

On RP2350, only the lower 46 IRQ signals are connected to system-level interrupt sources, and IRQs 46 to 51 are hardwired to zero (never firing). These six spare interrupts, referred to as SPAREIRQ_IRQ_0 through SPAREIRQ_IRQ_5 in the table, are deliberately reserved for the cores to interrupt themselves (via the Arm NVIC_ISPR0 registers or the Hazard3 MEIFA CSR), for example, when an interrupt handler wants to schedule a "bottom half" handler for work that must be done after exiting the interrupt handler, but before returning to the code running in the foreground.

Nested interrupts are supported in hardware: a lower-priority interrupt can be pre-empted by a higher-priority interrupt or fault, and will resume once the higher-priority handler returns. The pre-emption priority order is determined by the interrupt priority registers starting from NVIC_IPRO (Cortex-M33) or the MEIPRA interrupt priority array CSR (Hazard3).

When there is a choice of multiple interrupts to be entered at the same dynamic priority, the interrupt with the lowest IRQ number is chosen as a tie-breaker. The system-level IRQ numbering has been chosen to generally put higher-priority interrupts at lower IRQ numbers for this reason, though the true priority is often dependent on the specific application.

3.2.1. Non-maskable interrupt (NMI)

The system IRQ signals can be routed to the Cortex-M33 non-maskable interrupt (NMI) input, by setting the bit for that IRQ number in NMI_MASK0 or NMI_MASK1 . The non-maskable interrupt ignores the processor's interrupt enable/disable state ( PRIMASK ), and can pre-empt any other active interrupt. NMIs are generally used for emergent circumstances that require the processor's unconditional attention, such as loss of PLL lock or power supply integrity.

The NMI mask registers are core-local, so each core can have a different combination of interrupts routed to its NMI input. The NMI mask, along with all other EPPB registers, is reset by a warm reset of that core. This avoids an issue on RP2040 where the NMI mask could be left set following a processor reset.

In addition to system-level interrupts, the non-maskable interrupt is asserted when an integrity check is failed in the redundancy coprocessor (RCP, Section 3.6.3 ). This behaviour cannot be disabled, but a correctly-programmed RCP does not trigger under normal voltage, frequency, and temperature conditions. Likewise, if user code does not execute any RCP instructions, the RCP will never trigger. The RCP NMI output is asserted on both cores when an integrity check fails, and is de-asserted by a warm processor reset.

3.2.2. Further reading on interrupts

This section describes the routing of system-level interrupt requests to the processor subsystem. It omits important details such as the processor's response to receiving an interrupt, and how processors choose which system-level interrupt requests to subscribe to. The following is a selection of relevant information for these topics:

• • Section 3.7.2.5 describes the Cortex-M33's internal interrupt controller, the NVIC
• • Register listings starting from NVIC_ISERO describe controls for NVIC operation
• • Section 3.7.4.6 is an overview of Cortex-M33 exception handling

• • The Armv8-M Architecture Reference Manual describes detailed architecture rules for exception handling
• • Section 3.8.4 describes standard RISC-V trap handling
• • Section 3.8.4.2 describes the standard RISC-V external, timer and software interrupt requests, and how they are connected on RP2350
• • Section 3.8.6.1 describes the Xh3irq interrupt controller, which provides priority-controlled interrupt support for the system-level interrupts on Hazard3
• • Each peripheral has its own interrupt registers which control the assertion of its system-level interrupts listed in Table 95 – see peripheral documentation for more information

3.3. Event signals (Arm)

Using the WFE instruction, the Cortex-M33 can enter a sleep state until an "event" (or interrupt) takes place. It can also generate events using the SEV instruction. RP2350 cross-wires event signals between the two processors: an event sent by one processor will be received on the other.

i NOTE

The event flag is "sticky": if both processors send an event ( SEV ) simultaneously, then enter the sleep state ( WFE ), they will both wake immediately. This prevents the processors from getting stuck in a sleep state in this scenario.

Processors also receive an event signal from the global monitor if their reservation is lost due to a write by a different master, in accordance with Armv8-M architecture requirements.

While in a WFE (or WFI ) sleep state, the processor shuts off its internal clock gates to reduce power consumption. When both processors are in a sleep state and the DMA is inactive, all of RP2350 can enter a sleep state, disabling clocks on unused infrastructure such as the bus fabric. The rest of RP2350 wakes automatically when either of the processors wakes. See Section 6.5.2 .

3.4. Event signals (RISC-V)

The Hazard3 h3.block instruction halts processor execution until an unblock signal is received. The h3.unblock instruction sends an unblock signal to other processors. These NOP-compatible hint instructions are documented in Section 3.8.6.3 .

On RP2350 the Hazard3 unblock in/out signals are cross-connected between the two processors, and each processor's unblock output is also fed back into its input. The global monitor also posts an unblock signal to each core when that core loses a reservation due to an access by another core or the system DMA.

The Hazard3 MSLEEP CSR defines how deep a sleep the processor will enter when executing a h3.block instruction. By default this is a simple pipeline stall, but the processor can also gate its own clock and negotiate the system-level clock wake/sleep state with the clocks block ( Section 6.5.2 ).

The h3.unblock instruction is "sticky": an h3.block will fall through immediately if any unblock signal has been received since the last time the processor executed an h3.block instruction.

3.5. Debug

The Serial Wire Debug (SWD) bus provides access to hardware and software debug features including:

• • Loading firmware into SRAM or external flash memory

• • Control of processor execution: run/halt, step, set breakpoints, other standard debug functionality
• • Access to processor architectural state
• • Access to memory and memory-mapped IO via the system bus
• • Configuring the CoreSight trace hardware (Arm processors only)

The SWD bus is exposed on two dedicated pins, SWCLK and SWDIO. See Table 1430 for the pin definitions for SWCLK and SWDIO, and see Table 1440 for additional information on their specifications.

A single SW-DP provides access to RP2350's debug subsystem from the external SWCLK and SWDIO pins. The DP is multidrop-capable, but use of multidrop SWD is not mandatory. All hardware in the debug subsystem, with the exception of the RP-AP, can also be accessed directly from the system bus using the self-hosted debug window starting at CORESIGHT_PERIPH_BASE .

Figure 10. RP2350 debug topology. An SW-DP connects the external SWD pins to internal debug hardware. The ROM table lists debug components, for automatic discovery. AHB-APs provide debug access to Arm processors, and an APB-AP provides access to a standard RISC-V Debug Module. The RP-AP provides Raspberry-Pi-specific controls such as rescue reset and debug key entry. Remaining components are for Arm trace.

The numbers in brackets in Figure 10 are the addresses of the debug components within the debug address space. These correspond to values written to the SW-DP SELECT register for SWD accesses, or offsets from CORESIGHT_PERIPH_BASE for self-hosted debug access. All APs are accessible through the SW-DP, and all except the RP-AP are also accessible through self-hosted debug.

The SW-DP and RP-AP are in the always-on power domain, and are available once external power is applied and the power-on reset (POR) time has elapsed. All other APs in Figure 10 are available only once:

1. 1. the power manager (POWMAN) has sequenced the first power up of the switched core domain
2. 2. the OTP PSM has read critical hardware configuration flags from OTP
3. 3. the system clock ( clk_sys ) is running

3.5.1. Connecting to the SW-DP

The SW-DP defaults to the Dormant state at power-up or assertion of the external reset (RUN) pin. A Dormant-to-SWD sequence must be issued before beginning SWD operations. See the Arm Debug Interface specification, version 6, for details of Dormant/SWD state switching: https://developer.arm.com/documentation/ih0074/latest/

After a power-on, the following sequence can be used to connect to the SW-DP:

1. 1. At least \( 8 \times \) SWCLK cycles with SWDIO high.

1. 2. The 128-bit Selection Alert sequence: 0x19bc0ea2 , 0xe3ddafe9 , 0x86852d95 , 0x6209f392 , LSB-first.
2. 3. Four SWCLK cycles with SWDIO low.
3. 4. SWD activation code sequence : 0x1a , LSB first.
4. 5. At least 50 × SWCLK cycles with SWDIO high (line reset).
5. 6. A DPIDR read to exit the Reset state

In order to wake up the system from a low power (P1.x) state, set the CDBGPWRUPREQ in the DP CTRL/STAT register, then poll CDBGPWRUPACK in the same register until set. In low-power states, only the SW-DP and RP-AP are accessible, as the remaining debug logic is unpowered.

3.5.2. Arm debug

There are two AHB5 Mem-APs, at offsets 0x02000 and 0x04000 in the debug address space, which are used to debug the two Arm Cortex-M33 processors. Each Mem-AP is an AHB5 manager which accesses a 32-bit downstream address space. This is the same address space accessed by a processor's load/store instructions, which includes system-level hardware such as memory and peripherals, and processor-internal hardware on the processor's private peripheral bus (PPB). Certain PPB registers are visible only when accessed from the Mem-AP, not when accessed by software running on the processor.

The AHB5 Mem-AP's own register map is defined in Arm's ADIV6 specification. Generally this is only of interest to those implementing their own debug translator, and the Mem-AP can be thought of simply as a bridge between a DP (such as RP2350's SW-DP) and a downstream address space.

The standard Arm debug registers used to debug software running on the Cortex-M33 can be found documented in the Arm v8-M Architecture Reference Manual , or the Cortex-M33 Technical Reference Manual, available from Arm Ltd. This datasheet also documents the core's internal registers in Section 3.7.5 .

The Mem-APs can access system peripherals and memory at exactly the same addresses they would be accessed by software running on the processor. However, the privilege and security of Mem-AP accesses may be different from the security state of the software running on the processor at the point it halted: the privilege and security of Mem-AP accesses is configured explicitly via its control and status word (CSW) register. Care must be taken when debugging Non-secure software which accesses the SIO, for example, because by default the debugger may access the Secure alias of the SIO, not the Non-secure alias which software will have been accessing.

The bus filters configured by the ACCESSCTRL bus access permission registers ( Section 10.6.2 ) treat bus accesses originating from the Mem-APs as distinct from bus accesses originating from software running on the processor. This means it is possible to lock software out from a peripheral, whilst still allowing debugger access.

3.5.3. RISC-V debug

There is a single APB Mem-AP, at offset 0x0a000 in the debug address space, which provides access only to the RISC-V Debug Module (DM). The DM is a standard component which the debugger uses to enumerate RISC-V harts present in the system, debug software running on each hart, and access the system bus. It is defined in the RISC-V debug specification, of which RP2350 implements version 0.13.2.

From the point of view of the RISC-V debug specification, the SW-DP and APB Mem-AP function jointly as the Debug Transport Module for this system. The DM is located at offset 0x0 in the APB-AP's downstream address space, and the registers are word-sized and byte-addressed, meaning the DM register addresses in the debug specification must be multiplied by 4 to get the correct APB address.

On RP2350, each core possesses exactly one hardware thread (hart). Core 0 has a hart ID of 0, and core 1 has a hart ID of 1. These hart IDs match the hart index used in the DM. This DM is also equipped with the hart array mask select extension, which allows multiple cores to be reset/halted/resumed simultaneously.

The DM is equipped with the System Bus Access (SBA) extension, which allows the debugger to access the system bus without halting either core. This can be used for minimally intrusive debug techniques like Segger RTT. SBA accesses

arbitrate with core 1's load/store port to access the system bus, but they are treated as distinct from core 1's accesses for the purpose of bus filtering (Section 10.6.2), which means it is possible to lock software out of a peripheral whilst retaining debug access. Processor load/stores in Debug mode are also treated as debug accesses for the purpose of bus filtering.

The DM is able to reset each core individually using the dmcontrol.hartreset control. This resets only the selected processor. The dmcontrol.ndmreset resets both processors only , which is the minimum requirement in the RISC-V debug specification. A full system reset, which includes the DM, can be performed using the SYSRESETREQ control in the SW-DP, a switched core domain reset configured in POWMAN and initiated by the watchdog, or any full-system reset such as the RUN pin. A PSM reset initiated by the watchdog can reset almost all system-level hardware except for the DM, but note that the DM becomes momentarily inaccessible whilst the system clock's clock generator is reset, which is the reason for dmcontrol.ndmreset resetting the processors only.

For details on the processor side of RISC-V debug, see Section 3.8.5. See also the Hazard3 source code at github.com/Wren6991/Hazard3 , which includes the DM implementation under the hdl/debug/dm/ directory.

3.5.4. Debug power domains

The SW-DP and the RP-AP are in the always-on power domain. This means they are available even when the system is in its lowest-power state, with the switched core domain (which includes the processors) fully powered down.

The remainder of the debug hardware is in the switched core domain. This is the same domain as the processors and system peripherals.

Setting the CDBGPWRUPREQ bit in the SW-DP's CTRL/STAT register will force a power up of the switched core domain, making the remaining debug hardware available. This power up takes some time, as it is sequenced by the 32 kHz low-power oscillator (Section 8.4), so the CDBGPWRUPACK bit must be polled to wait for the system to power up before attempting to access any APs other than the RP-AP. See Arm's ADIV6 specification for the SW-DP's register listing.

Note that the RP-AP is accessible without asserting CDBGPWRUPREQ , as it is always powered.

3.5.5. Software control of SWD pins

The DBGFORCE register in SYSCFG can be used to detach the SW-DP from the external debug pads, and instead bitbang the internal SWD signals directly from software. This is intended for a debug probe running on one core being used to debug the other core. For other use cases it is generally cleaner to use the self-hosted debug access to interface with the APs directly from the system bus.

3.5.6. Self-hosted debug

All APs shown in Figure 10, except for the RP-AP, have direct memory-mapped access from the system bus. This is known as self-hosted debug, because with care it allows running a debug host (i.e. a debugger) directly on-system. It can also be used to access the trace hardware, which can be used for self-hosted trace using the trace DMA FIFO. By default only Secure access is permitted, as the processor debug presents an opportunity for Non-secure code to interfere with the Secure context and/or perform Secure bus accesses.

The self-hosted debug window starts at address 0x40140000 ( CORESIGHT_PERIPH_BASE ). The offsets of the APs within this window are the same as the APs' addresses when accessed from the SW-DP.

Because of the blocking nature of the AHB-AP's DRW register, and its interactions with the Cortex-M33's arbitration of AHB-AP accesses with load/stores, certain accesses have potential to cause bus lockup due to circular bus stall dependencies. In particular, cores may not access their own AHB-APs through the self-hosted debug window, and AHB-APs may not access AHB-APs through the self-hosted debug window — attempting to do so will immediately return a bus fault. To reduce the opportunities for deadlock, a full APB crossbar is used to connect the SW-DP and the self-hosted debug port to the APs, so that for example self-hosted use of the Arm trace hardware will not interfere with an external debugger attaching via the AHB-APs.

There are some cases where a bus deadlock can not be avoided, such as a core using the other core's AHB-AP, via the self-hosted debug window, to access some other APB peripheral:

1. 1. The access upstream of the APB's DRW register will not complete until the downstream access completes
2. 2. The downstream access will not complete until it is granted access to the system APB bridge
3. 3. Access to the APB bridge will not be granted until the upstream access, which is occupying the system APB bridge, completes
4. 4. See point 1.

This situation can arise when running a self-hosted debugger on one core, and debugging code on the other core which accesses APB addresses. The deadlock is eventually broken when the APB bridge's 65536-cycle timeout expires, abandoning the transfer and returning a bus error to the origin of the upstream access. To avoid this, software should detect when it is about to use an AP to access an APB address (an address starting with 0x4 ), and perform the access directly instead of using the Mem-AP.

This type of deadlock does not occur when the debugger accesses the bus with RISC-V System Bus Access, because the bus transfer upstream of the DM does not block on completion of the downstream access.

3.5.7. Trace

3.5.7.1. Overview

The ATB trace subsystem is based on the Coresight SoC-600M architecture, as shown in Figure 11 .

Figure 11. Trace Subsystem

The trace subsystem captures trace messages from each of the Cortex-M33 ITM/ETM components, merges them into a single trace bus, and sends off-chip through the 4-bit DDR trace port for subsequent capture and analysis by a trace port analyser.

This allows the developer to review a detailed log of software executed on the processors. The advantage over conventional hardware debug is that it does this without halting the processors or affecting their execution timing, so you can diagnose software issues that are hard to reproduce under a debugger.

The trace subsystem comprises the following main components:

• • Timestamp Generator: Timestamps propagate to both Cortex-M33 processors, and are applied to ETM and ITM output so that the relative timing of their trace streams can be recovered.
• • Cortex-M33 ETM: Embedded Trace Macrocell, for real-time instruction flow messages generated from observations of the Cortex-M33's execution.
• • Cortex-M33 ITM: Instruction Trace Macrocell, for software-generated messages.
• • ATB Funnel: Merges the Cortex-M33 trace sources into a single trace stream using the timestamps from the Timestamp Generator.
• • TPIU: Trace Port Interface Unit, outputs trace data over trace port pins. The source-synchronous trace interface is 4-bits DDR, up to 75 MHz clock, giving a maximum trace data rate of up to 600 Mb/s.

• • Trace FIFO: Optionally captures the 32-bit TPIU trace stream on-device, from which point the DMA can transfer to main system SRAM.

See the Arm CoreSight ETM-M33 Technical Reference Manual for information about the Cortex-M33 ETM. See the SoC-600M Technical Reference Manual for information about the other trace components in Figure 11

The trace output clock is fixed at one half of clk_sys . At the maximum system frequency of 150 MHz this yields a 75 MHz TPIU output clock. The trace throughput is reduced at lower system clock frequencies, though this is rarely an issue in practice as the processor instruction throughput (and therefore the demand for trace output bandwidth) scales accordingly.

3.5.7.2. Trace FIFO

Trace output goes to one of two data sinks:

• • The four-bit TPIU interface streams data out of the chip through GPIOs, for capture by an external probe
• • The trace FIFO streams data into SRAM via the system DMA

The bandwidth of the DMA is greater than the bandwidth of the TPIU interface. Capturing into an on-chip buffer also allows trace to operate through a comparatively low-speed SWD probe without restricting trace bandwidth.

The operation is similar to a micro-trace buffer (MTB). However, all of system SRAM is available for trace. You can also use other DMA endpoints like the PIO and HSTX to implement your own trace data sinks, for example if you would prefer a wider and lower-frequency bus than the TPIU provides.

You must enable DMA access to the trace FIFO registers by setting the DMA bit in the ACCESSCTRL CORESIGHT_TRACE register before attempting to DMA from this FIFO. Configure the DMA for DREQ 53 to select the trace FIFO.

3.5.7.3. List of trace FIFO registers

The trace FIFO registers start at a base address of 0x50700000 (defined as CORESIGHT_TRACE_BASE in the SDK).

Table 96. List of CORESIGHT_TRACE registers

CORESIGHT_TRACE: CTRL_STATUS Register

Offset: 0x0

Description

Control and status register

Table 97. CTRL_STATUS Register

CORESIGHT_TRACE: TRACE_CAPTURE_FIFO Register

Offset: 0x4

Description

FIFO for trace data captured from the TPIU

Table 98.
TRACE_CAPTURE_FIFO
Register

3.5.8. Rescue reset

A rescue reset is a full system reset, similar to asserting the RUN pin low, which also sets a flag telling the bootrom to halt before running any user software. This is performed over the SWD bus using the RP-AP, and can be performed even when system clocks are stopped and the switched core power domain is powered down. This is used in the case where the chip has locked up, for example if code has been programmed into flash which permanently halts the system clock: since the debugger can no longer communicate with the processors to return the system to a working state, more drastic action is needed. This functionality was provided by the Rescue DP on RP2040, but on RP2350 it is provided by the RP-AP, to avoid mandatory use of multidrop SWD.

A rescue is invoked by setting and then clearing the CTRL.RESCUE_RESTART bit in the RP-AP. This causes a hard reset of the chip, and sets CHIP_RESET.RESCUE_FLAG to indicate that a rescue reset took place. The bootrom checks this flag almost immediately in the initial boot process (before watchdog, flash or USB boot), acknowledges by clearing the bit, then halts the processor. This leaves the system in a safe state, with the system clock running, so that the debugger can reattach to the cores and load fresh code.

3.5.9. Security

By default, the SWD debug access port allows an external debugger to access all system memory and peripherals, and to observe and change the execution of software running on the processors. If boot signature enforcement is enabled (Section 10.1.1), debug access becomes a security concern, as it is able to sidestep this protection. To account for this, RP2350 supports progressively locking down the debug port using configuration in on-chip OTP storage.

Conceptually there are two control bits: debug disable, and secure debug disable. Debug disable is intended to completely cut off debug access to the processors and the system bus, whilst the secure debug disable forbids Secure bus accesses, and halting of processors in the Secure state, but still allows Non-secure software to be debugged as normal. There are two ways to set these control bits:

• • Setting the relevant OTP critical flag: CRIT1.DEBUG_DISABLE or CRIT1.SECURE_DEBUG_DISABLE to set the debug disable or secure debug disable, respectively
• • Installing a 128-bit fixed debug key as OTP key 5 or 6 (Section 3.5.9.2)

OTP configuration changes take effect at the next reset of the OTP block.

Once debug has been disabled, software can re-enable debug using the OTP DEBUGEN register, which allows the secure and overall debug enable to be cleared individually for each processor. For example, Secure software may implement a shell where users can authenticate using a cryptographic challenge to enable debug on systems where it is disabled by default. The DEBUGEN register belongs to the processor cold reset domain, so it is preserved over a PSM reset starting from as early as OTP (the second PSM stage). This allows almost a full system reset without losing debug access.

To avoid accidental writes of the DEBUGEN register, its bits can be individually locked using the matching bits in DEBUGEN_LOCK .

This offers increasing levels of debug protection:

1. 1. Fully open: no keys installed and no OTP debug disable flags are set. This is the most convenient configuration for product development.
2. 2. Access with key only: at least one key is installed, but no OTP debug disable flags are set.
3. 3. No access even with key (an OTP debug disable flag is set), but Secure code can enable debug access by writing to DEBUGEN .
4. 4. No access even with key (an OTP debug disable flag is set), and DEBUGEN is locked by DEBUGEN_LOCK .

3.5.9.1. Effects of debug disables

The secure debug disable flag ( CRIT1.SECURE_DEBUG_DISABLE ) has the following effects:

• • Set Secure AP enable signals for Arm core 0 and core 1 AHB-APs to 0.
  • ◦ This prevents the APs from performing Secure bus accesses (including to the PPB).
  • ◦ Status is reported in the SDeviceEn flag of the AHB-AP CSW register.
• • Set the Cortex-M33 SPIDEN and SPNIDEN signals for both cores to 0.
  • ◦ This prevents the cores from being halted or traced whilst in the Secure state.
• • Disable the factory test JTAG interface (Section 10.10).

Both AHB-APs' CSW.HNONSEC bits default to 0, generating Secure bus accesses. If the secure debug disable flag is set, these bits must be set to 1 to generate Non-Secure bus accesses.

The debug disable flag ( CRIT1.DEBUG_DISABLE ) has all of the effects of the secure debug disable flag. It also has the following additional effects:

• • Set AP enable signals for Arm core 0 and core 1 AHB-APs to 0.
  • ◦ This prevents the APs from performing any bus accesses at all (including to the PPB).
  • ◦ Status is reported in the DeviceEn flag of the AHB-AP CSW register.
• • Set AP enable signal for RISC-V DM APB-AP to 0.
  • ◦ This prevents the AP from accessing the RISC-V Debug Module.
  • ◦ Status is reported in the DeviceEn flag of the APB-AP CSW register.
• • Set DBGEN and NIDEN signals for the CTI to 0.

On RISC-V CRIT1.SECURE_DEBUG_DISABLE has no useful effect. Debug-mode accesses from the cores always have Secure and Privileged bus attributes, except when reduced by FORCE_CORE_NS . Likewise, System Bus Access via the Debug Module is always Secure and Privileged, unless FORCE_CORE_NS.CORE1 is set, in which case it is Non-secure and Privileged. Use the CRIT1.DEBUG_DISABLE flag on RISC-V.

3.5.9.2. Debug keys

Section 13.5.2 describes the OTP hardware access keys. Hardware reads OTP access keys into hidden registers as part of the OTP power-up sequence which takes place after an OTP reset, and the corresponding OTP locations then become inaccessible. OTP keys 5 and 6 are special in that they control access to the SWD debug hardware in addition to functioning as normal OTP page keys.

A debug key is a 128-bit fixed challenge. Installing a debug key in OTP locks down debug access, and it remains locked until the debug host writes a matching key value through the RP-AP DBGKEY register. This is a write-only interface.

To install a debug key, first program the OTP locations starting from KEY5_0 or KEY6_0 . These locations are ECC-protected. Once you have programmed the 128-bit key value and read it back to confirm the correct value is programmed, write the raw bit pattern 0x010101 to KEY5_VALID or KEY6_VALID to mark the key as valid. The validity takes effect at the next reset of the OTP block.

Once a key is valid, the OTP storage locations for that key become inaccessible for both reads and writes. Only the OTP power-up state machine (Section 13.3.4) can read the key.

The effect of installing debug keys depends on which of key 5 and 6 are installed:

• • If key 5 or key 6 is valid, and no matching key (either) has been entered through the RP-AP, all debug is disabled. This has the same effect as setting CRIT1.DEBUG_DISABLE .
• • If key 5 is valid, and no matching key (key 5 specifically) has been entered through the RP-AP, Secure debug is disabled. This has the same effect as writing CRIT1.SECURE_DEBUG_DISABLE .

When both keys are installed, key 5 provides both Secure and Non-secure debug access, and key 6 provides Non-secure debug access only. When only a single key is installed, that key provides both Secure and Non-secure debug access.

To enter a key over SWD, first write a 1 to DBGKEY.RESET . Then sequentially write 128 bits to DBGKEY.DATA , each accompanied by a 1 written to DBGKEY.PUSH . Write the data LSB-first, starting with the lowest-numbered OTP row.

Assuming you wrote a value that matched one of the installed debug keys, debug unlocks after the 128th push. The SDeviceEn and DeviceEn flags in the Mem-AP CSW registers indicate success or failure.

Failure to supply a matching key through the RP-AP disables debug if it would otherwise be enabled. However, supplying a key does not enable if it is already disabled for other reasons. For example, if CRIT1.DEBUG_DISABLE is set, and

DEBUGEN is clear, debug is be disabled no matter the state of the debug keys and the RP-AP.

3.5.10. RP-AP

The RP-AP is a small register block which is always accessible over SWD. RP-AP access does not require the switched core domain to be powered up, or any internal system clock generators to be running.

3.5.10.1. List of registers

The RP-AP registers start at offset 0x80000 in the debug address space, which is accessed via address 0x80000 in the SW-DP's SELECT register. Unlike the other APs, it can not be accessed directly from the system bus.

Table 99. List of RP-AP registers

RP_AP: CTRL Register

Offset: 0x000

Description

This register is primarily used for DFT but can also be used to overcome some power up problems. However, it should not be used to force power up of domains. Use DBG_POW_OVRD for that.

Table 100. CTRL Register

RP_AP: DBGKEY Register

Offset: 0x004

Description

Serial key load interface (write-only)

Table 101. DBGKEY Register

RP_AP: DBG_POW_STATE_SWCORE Register

Offset: 0x008

Description

This register indicates the state of the power sequencer for the switched-core domain.

The sequencer timing is managed by the POWMAN_SEQ_* registers. See the header file for those registers for more information on the timing.

Power up of the domain commences by clearing bit 0 (IS_PD) then bits 1-8 are set in sequence. Bit 8 (IS_PU) indicates the sequence is complete.

Power down of the domain commences by clearing bit 8 (IS_PU) then bits 7-1 are cleared in sequence. Bit 0 (IS_PU) is then set to indicate the sequence is complete.

Bits 9-11 describe the states of the power manager clocks which change as clock generators in the switched-core become available following switched-core power up.

This bus can be sent to GPIO for debug. See DBG_POW_OUTPUT_TO_GPIO in the DBG_POW_OVRD register.

Table 102.
DBG_POW_STATE_SW
CORE Register

RP_AP: DBG_POW_STATE_XIP Register

Offset: 0x00c

Description

This register indicates the state of the power sequencer for the XIP domain.

The sequencer timing is managed by the POWMAN_SEQ_* registers. See the header file for those registers for more information on the timing.

Power up of the domain commences by clearing bit 0 (IS_PD) then bits 1-8 are set in sequence. Bit 8 (IS_PU) indicates the sequence is complete.

Power down of the domain commences by clearing bit 8 (IS_PU) then bits 7-1 are cleared in sequence. Bit 0 (IS_PU) is then set to indicate the sequence is complete.

Table 103.
DBG_POW_STATE_XIP
Register

RP_AP: DBG_POW_STATE_SRAM0 Register

Offset: 0x010

Description

This register indicates the state of the power sequencer for the SRAM0 domain.

The sequencer timing is managed by the POWMAN_SEQ_* registers. See the header file for those registers for more information on the timing.

Power up of the domain commences by clearing bit 0 (IS_PD) then bits 1-8 are set in sequence. Bit 8 (IS_PU) indicates the sequence is complete.

Power down of the domain commences by clearing bit 8 (IS_PU) then bits 7-1 are cleared in sequence. Bit 0 (IS_PU) is then set to indicate the sequence is complete.

Table 104.
DBG_POW_STATE_SR
AM0 Register

RP_AP: DBG_POW_STATE_SRAM1 Register

Offset: 0x014

Description

This register indicates the state of the power sequencer for the SRAM1 domain.

The sequencer timing is managed by the POWMAN_SEQ_* registers. See the header file for those registers for more information on the timing.

Power up of the domain commences by clearing bit 0 (IS_PD) then bits 1-8 are set in sequence. Bit 8 (IS_PU) indicates the sequence is complete.

Power down of the domain commences by clearing bit 8 (IS_PU) then bits 7-1 are cleared in sequence. Bit 0 (IS_PU) is then set to indicate the sequence is complete.

Table 105.
DBG_POW_STATE_SR
AM1 Register

RP_AP: DBG_POW_OVRD Register

Offset: 0x018

Description

This register allows external control of the power sequencer outputs for all the switched power domains. If any of the power sequencers stall at any stage then force power up operation of all domains by running this sequence:

• • set DBG_POW_OVRD = 0x3b to force small power switches on, large power switches off, resets on and isolation on
• • allow time for the domain power supplies to reach full rail
• • set DBG_POW_OVRD = 0x3b to force large power switches on
• • set DBG_POW_OVRD = 0x37 to remove isolation
• • set DBG_POW_OVRD = 0x17 to remove resets

Table 106.
DBG_POW_OVRD
Register

RP_AP: DBG_POW_OUTPUT_TO_GPIO Register

Offset: 0x01c

Description

Send some, or all, bits of DBG_POW_STATE_SWCORE to gpios.

Bit 0 sends bit 0 of DBG_POW_STATE_SWCORE to GPIO 34

Bit 1 sends bit 1 of DBG_POW_STATE_SWCORE to GPIO 35

Bit 2 sends bit 2 of DBG_POW_STATE_SWCORE to GPIO 36

1. +

2. + Bit 11 sends bit 11 of DBG_POW_STATE_SWCORE to GPIO 45

Table 107.
DBG_POW_OUTPUT_TO_GPIO Register

RP_AP: IDR Register

Offset: 0xdfc

Table 108. IDR Register

3.6. Cortex-M33 coprocessors

The Cortex-M33 features a coprocessor port which transfers up to 64 bits per cycle between the processor and certain closely-coupled hardware. The Cortex-M33's built-in floating-point unit is an example of such a coprocessor, but RP2350 adds three device-specific coprocessors to this interface. The following sections document these coprocessors.

Before accessing a coprocessor from Secure code, that coprocessor must first be enabled by setting the corresponding bit in the CPACR. Before accessing from the Non-secure state, the corresponding bits in the NSACR and CPACR_NS registers must be set.

The RISC-V processors on RP2350 do not have access to the Cortex-M33 coprocessors.

3.6.1. GPIO coprocessor (GPIOC)

Coprocessor port 0 provides low-overhead access from the Cortex-M33 processors to the GPIO registers in the SIO (Section 3.1.3). This enables a single coprocessor instruction to sample all 48 GPIOs, or to set/clear/write any single GPIO, among other functionality.

Non-secure accesses are filtered according to the GPIO_NSMASK0 and GPIO_NSMASK1 registers in ACCESSCTRL. GPIOs not granted for Non-secure use will ignore writes from the Non-secure state, and read back as zero when read from the Non-secure state.

3.6.1.1. OUT mask write instructions

These instructions write to multiple bits in the SIO GPIO_OUT and GPIO_HI_OUT registers.

3.6.1.2. OE mask write instructions

These instructions write to multiple bits in the SIO GPIO_OE and GPIO_HI_OE registers.

3.6.1.3. Single-bit write instructions

These instructions write to a single, indexed bit in either the GPIO_OUT and GPIO_HI_OUT registers, or the GPIO_OE and GPIO_HI_OE registers.

3.6.1.4. Indexed mask write instructions

These instructions write to a single, dynamically selected 32-bit GPIO register.

3.6.1.5. Read instructions

These instructions read from either the GPIO_OUT and GPIO_HI_OUT registers; the GPIO_OE and GPIO_HI_OE registers; or the GPIO_IN and GPIO_HI_IN registers.

3.6.1.6. Interpreting instruction fields

The type of coprocessor instruction — mrc , mrrc , mcr and mccr — specifies the direction of the transfer (read/write) and the number of Arm registers being transferred (one or two).

Bits 3:2 of the first coprocessor register number field, CRm , identify the group of registers being accessed. Values 0, 1 and

2 refer to the output, output enable and input registers respectively.

Bit 0 of the first coprocessor register number field, CRm , may be used to distinguish which register in a group is being accessed. Bit 1 is reserved to allow more registers to be indexed on future chips with more GPIOs.

For writes, bits 1:0 of the instruction's opc1 field specify the type of write operation: values 0, 1, 2, 3 map to normal write, XOR, set and clear operations respectively. Bits 3:2 of the opc1 field are used to indicate the addressing mode for the register or individual bit being accessed. Their exact interpretation depends on the instruction.

Any combinations not listed in the preceding tables are reserved for future use.

3.6.2. Double-precision coprocessor (DCP)

Each Cortex-M33 CPU core is equipped with two instances of a double-precision coprocessor that provides acceleration of double-precision floating point operations including add, subtract, multiply, divide and square root. The design is implemented in just a few thousand gates and so occupies much less silicon die area than a full double-precision floating-point unit.

Nevertheless, these coprocessors considerably speed up basic double-precision operations compared to pure software implementations. The coprocessors also offer support for some single-precision operations and conversions.

The two coprocessor instances are assigned to the Secure and Non-secure domains. Coprocessor number 4 always maps to the coprocessor used for the current processor security state. Coprocessor number 5 always maps to the Non-secure coprocessor instance, but is accessible only from Secure code. This duplication avoids saving and restoring the coprocessor context during Secure/Non-secure state transitions.

3.6.2.1. CPU interface

As with the other coprocessors, the accelerator connects to the CPU over a 64-bit bus. Two words of data can be transferred per cycle over that bus using the following instructions:

• • MCRR : move two integer registers to coprocessor
• • MRRC : move two integer registers from coprocessor

There are also single-register versions of these instructions, including ones that allow the CPU's flags to be loaded from the coprocessor. The CPU issues CDP instructions to trigger operations within the coprocessor without transferring any data.

3.6.2.2. Internal architecture

A block diagram of the accelerator is shown in Figure 12 .

Figure 12. Block diagram of double-precision accelerator

At the heart of the design are:

• • two sets of registers, each designed to hold an unpacked double-precision value
• • a 9-bit status register

Unlike a conventional FPU, the accelerator does not contain a full register bank. Not only does this save die area, it also means that saving and restoring the coprocessor's state is very fast: in fact, the entire state fits within six 32-bit words and hence can be saved to, or restored from, the CPU in three instructions.

The accelerator contains a wide adder, capable of adding two mantissa values and three exponent values simultaneously. There is also a shifter that can either perform a logical right shift by a given amount, or normalise a denormalised mantissa and report the amount of shift required to do so. A considerable amount of hardware in the shifter is shared between these two operating modes.

Control logic, shown at the top of the diagram, decodes coprocessor instructions and configures the accelerator's functional units and datapath multiplexers in order to execute the desired operation. Each coprocessor instruction takes a single cycle, so coprocessor operations cannot stall the CPU.

A floating-point operation such as addition or subtraction is carried out by executing a fixed (or 'canned') sequence of instructions as follows:

1. 1. One or two MCRR instructions to write the operands to the coprocessor.
2. 2. A number of CDP (and possibly other) instructions that together perform the operation itself.
3. 3. An MRRC or MRC instruction to read back the result.

The hardware handles special cases involving zeroes, NaNs, and infinities, as well as rounding, underflow and overflow.

The accelerator does not contain a multiplier array, as that would occupy a considerable amount of die area. Instead, the mantissas of the operands of a multiplication operation are brought back into the CPU to take advantage of the fast long multiply instructions available there. The coprocessor handles the processing of exponents.

Division and square root operations also involve data moving back and forth between coprocessor and CPU. To assist with these operations, the coprocessor contains two small lookup tables (implemented as random logic) that provide initial approximations used in the divide and square root algorithms. The coprocessor handles the processing of exponents.

The accelerator is only meant to be used with the canned instruction sequences that implement basic floating-point operations. The state of the accelerator is not guaranteed to be preserved from the end of one canned sequence to the beginning of the next: see the discussion of the 'engaged' flag in the status register below.

3.6.2.3. Registers

X and Y mantissa registers

The X and Y mantissa registers ( xm and ym ) are each 64 bits wide. They can be read and written directly by the CPU; the xm register can also store the lower part of the result from the adder. When a value is written to the coprocessor using a 'write unpacked' MCRR instruction, the top two bits of the mantissa register are set to 01 and the next most significant bits are filled from the mantissa field of the floating-point operand. The low-order bits of the mantissa register are cleared.

X and Y exponent registers

The X and Y exponent registers ( xe and ye ) are each 14 bits wide. They can be read and written directly by the CPU; the xe register can also store the higher part of the result from the adder. When a value is written to the coprocessor using a 'write unpacked' MCRR instruction, the exponent register is set from the exponent field of the floating-point operand.

X and Y flag registers

The X and Y flag registers ( xf and yf ) are each four bits wide. They can be read and written directly by the CPU. The flag register stores information about the type of floating-point number represented in the corresponding mantissa and exponent registers: its sign, whether it is a zero, whether it is an infinity, and whether it is a NaN. When a value is written to the coprocessor using a 'write unpacked' MCRR instruction, the bits of the flag register are updated according to the type of the floating-point operand.

Status register

The status register contains nine bits. It can be read and written directly by the CPU. The least significant six bits of the register store the shift required to align the two operands of an addition or subtraction; the next two bits indicate whether the value represented by ( xe , xm ) is greater than, equal to, or less than the value represented by ( ye , ym ) - in other words, whether the magnitude of the value stored in the X registers is greater than, equal to, or less than the magnitude of the value stored in the Y registers. These status bits are set in the first step of an addition, subtraction or comparison operation after the operands have been loaded.

The final bit of the status register indicates whether the coprocessor is 'engaged'. The engaged flag is set by all coprocessor instructions that occur at the beginning or in the middle of the canned instruction sequences. It is cleared by those instructions used at the end of a canned sequence to read back a final result.

3.6.2.4. State save and restore

An interrupt handler can test the engaged flag to determine whether it has pre-empted an in-progress operation on the same coprocessor. If the engaged flag is set, the handler can save (and restore) the coprocessor state before using the coprocessor. If the engaged flag is clear, the save (and restore) step can be skipped. If this approach is implemented, the state of the accelerator must be regarded as undefined when not within one of the canned instruction sequences.

Three MRRC instructions are provided to copy the six words of state in the coprocessor into integer registers in the CPU, from where they can, for example, be pushed onto the stack. The last of these instructions clears the engaged flag.

Similarly, three MCRR instructions are provided to restore the state of the coprocessor from integer registers, including the state of the engaged flag.

3.6.2.5. Instruction summary

As mentioned above, it is intended that the coprocessor instructions are only used as part of canned sequences. Nevertheless, for completeness, a list of the available instructions is given here with an outline of their effects.

MCRR instructions are shown in Table 109 .

Table 109. MCRR instructions

CDP instructions are shown in Table 110 .

Table 110. CDP instructions

MRRC and MRC instructions are shown in Table 111 .

Table 111. MRRC and MRC instructions

Alongside each MRRC and MRC instruction is a variant starting P (for 'peek') instead of R that has the same function but preserves the engaged flag. RXMD is identical to PXMD ; REFD is identical to PEFD .

The SDK includes macros to generate Arm assembler from the mnemonics above in the file dcp_instr.inc.S in the SDK, for example turning WXUP r0,r1 into mcrr p4,#1,r0,r1,c0 .

3.6.2.6. Example canned sequence

The assembly code sequence to implement a callable double-precision addition operation is shown in Table 112 .

Table 112. Assembly code sequence to implement a callable double-precision addition operation

Logic in the coprocessor ensures, for example, that the ADD1 instruction shifts the smaller argument, that xm and ym are negated as required before being sent to the adder, and that the larger exponent is used as the basis for the subsequent normalisation.

3.6.2.7. Using the coprocessor via the SDK library

The SDK pico_double library automatically uses the coprocessor for double-precision floating-point calculations. This is the simplest way to take advantage of the coprocessor, but it entails a few cycles of overhead for each operation. Not only is there the overhead involved in a function call and return, but for safety the general-purpose implementations in the SDK always test the engaged flag, saving and restoring the coprocessor state to and from the stack as needed. That ensures that the functions work correctly if used in interrupt handlers, without additional intervention.

3.6.2.8. Using the coprocessor directly

The SDK includes macros to generate canned sequences for standard operations in the file dcp_canned.inc.S in the SDK.

These allow the callable double-precision addition operation listed above, for example, to be written as:

dcp_dadd_m r0,r1, r0,r1,r2,r3 @ result in r0,r1; operands in r0,r1 and r2,r3
bx r14

dcp_dadd_m is a macro which expands into the sequence of coprocessor instructions given above. This macro allows you to specify the integer registers to be used for the operands and the result, which means that using these macros directly not only avoids function call and return overhead, it also avoids the extra overhead associated with argument marshalling.

The more complex macros also require you to specify 'scratch' registers that they can use for storing intermediate results. The following function, which calculates the dot product of two three-element vectors of doubles pointed to by R0 and R1 , illustrates this:

push {r4-r9,r14}
ldrd r3,r4,[r0],#8           @ load x0
ldrd r5,r6,[r1],#8           @ load y0
dcp_dmul_m r7,r8, r3,r4,r5,r6, r3,r4,r5,r6,r12,r14,r9 @ compute x0y0 ①
ldrd r3,r4,[r0],#8           @ load x1
ldrd r5,r6,[r1],#8           @ load y1
dcp_dmul_m r3,r4, r3,r4,r5,r6, r3,r4,r5,r6,r12,r14,r9 @ compute x1y1 ①
dcp_dadd_m r7,r8, r3,r4,r7,r8 @ compute x0y0+x1y1
ldrd r3,r4,[r0],#8           @ load x2
ldrd r5,r6,[r1],#8           @ load y2
dcp_dmul_m r3,r4, r3,r4,r5,r6, r3,r4,r5,r6,r12,r14,r9 @ compute x2y2 ①
dcp_dadd_m r0,r1, r3,r4,r7,r8 @ compute x0y0+x1y1+x2y2 ②
pop {r4-r9,r15}

1. 1. r3, r4, r5, r6, r12, r14 , and r9 are scratch registers.
2. 2. stores the result in r0, r1 .

NOTE

This example does not check the engaged flag. If used in interrupt handlers or in multi-threaded applications, a suitable test would have to be added. For example, see the SDK implementation of __aeabi_dadd for an efficient way to do this. The test only needs to be performed once, at the beginning of the function, so the overhead in this case would be relatively small.

The following example demonstrates how to use the coprocessor:

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/dcp/hello_dcp/hello_dcp.c Lines 18 - 109

18 extern double dcp_dot           (double*p, double*q, int n);
19 extern double dcp_dotx          (float*p, float*q, int n);
20 extern float  dcp_iirx          (float x, float*temp, float*coeff, int order);
21 extern void   dcp_butterfly_radix2 (double*x, double*y);
22 extern void   dcp_butterfly_radix2_twiddle_dif (double*x, double*y, double*tf);
23 extern void   dcp_butterfly_radix2_twiddle_dit (double*x, double*y, double*tf);
24 extern void   dcp_butterfly_radix4  (double*w, double*x, double*y, double*z);
25
26 static void dcp_test0() {
27     double u[3]={1,2,3};
28     double v[3]={4,5,6};
29     double w;
30     w=dcp_dot(u,v,3);
31     printf("(1,2,3).(4,5,6)=%g\n",w);
32 }
33
34 static void dcp_test1() {
35     float u[3]={1+pow(2,-20),2,3};
36     float v[3]={1-pow(2,-20),5,6};
37     double w;
38     w=dcp_dotx(u,v,3);

100     dcp_test1();
101     dcp_test2();
102     dcp_test3();
103     dcp_test4();
104     dcp_test5();
105     dcp_test6();
106
107     return 0;
108 }

There are also further examples in the dcp/ directory in the Pico Examples repository.

3.6.2.9. IEEE 754 compliance

The canned instruction sequences provide IEEE-compliant operations with the exception that denormals are flushed to zero on input and output. Zeroes, NaNs and infinities are correctly handled. Rounding is to nearest, even on tie.

Faster versions of division and square root operations, named ddiv_fast and dsqrt_fast respectively, are available. These do not always give correctly rounded results but do have a guaranteed error before rounding of less than 0.5ulp ('units in last place'), which in particular means that if there is an exact representation of the result then that is what is returned.

3.6.2.10. Benchmarks

Table 113 gives cycle counts for various floating-point operations using the accelerator with inlined code, compared to some typical ranges of benchmarks for (a) fully-fledged hardware double-precision FPUs; and (b) pure software implementations.

Table 113. Cycle counts for floating-point operations using the accelerator

3.6.3. Redundancy coprocessor (RCP)

Figure 13. The redundancy coprocessor implements hardware-checked assertions, to aid control flow and data flow integrity checking. Its two-phase pipeline is closely coupled to the Cortex-M33 pipeline. A 64-bit salt register holds a once-per-boot random number, which is used to generate and validate stack canary values and generate pseudorandom delay sequences on RCP instructions. Other comparison functions provide more general hardware-checked assertion support.

The redundancy coprocessor (RCP) is used in the RP2350 bootrom to provide hardware-assisted mitigation against fault injection and return-oriented programming attacks. This includes the following instructions:

• • generate and validate stack canary values based on a per-boot random seed
• • assert that certain points in the program are executed in the correct order without missing steps
• • validate booleans stored as one of two valid bit patterns in a 32-bit word
• • validate 32-bit integers stored redundantly in two words with an XOR parity mask
• • halt the processor upon reaching a software-detected panic condition

Section 3.6.3.7 lists the RCP instruction set in full. RCP instruction encodings contain a parity bit; executing an invalid instruction or an instruction with bad parity triggers an RCP fault.

Each Cortex-M33 processor is equipped with a single RCP instance, mapped as coprocessor number 7 in the coprocessor opcode space. The two RCP instances are linked: an RCP fault on one core immediately triggers a fault on the other. RCP faults have two steps:

1. 1. The non-maskable interrupt (NMI) is asserted. It remains asserted until a warm reset of the processor.
2. 2. Any further RCP instructions stall the coprocessor port until a warm reset of the processor. This stall cannot be interrupted, as the processor is already in the NMI state.

The RP2350 bootrom implements the NMI and HardFault vectors with an rcp_panic instruction. This instruction unconditionally stalls the coprocessor port. This prevents the processor from retiring any more instructions until either a debugger connects to reset the processors, or the processors reset through some other mechanism (such as the system watchdog timer). The processor quickly reaches a quiescent state that reduces vulnerability to further fault injection (deliberate or otherwise).

Each core's RCP has a 64-bit seed value (Section 3.6.3.1). The RCP uses this value to generate stack canary values and to add short pseudorandom delays to RCP instructions. Both RCP instances are seeded by core 0 during the early boot path in the bootrom using the system true-random number generator (Section 12.12). Running any RCP instruction before providing a salt value triggers an RCP fault. The use of random data in stack canary values makes it difficult to reuse return-oriented-programming stack payloads across multiple boots.

Figure 13 gives a dataflow-level overview of the RCP hardware. The RCP is structured as a two-phase pipeline which overlays the Cortex-M33 execution pipeline. It exchanges data with the core via a 64-bit incoming bus (CPWDATA) and a 32-bit outgoing bus (CPRDATA). The Cortex-M33 can issue two register reads to the coprocessor in one cycle through the CPWDATA bus. The RCP leverages this throughput for some of its assertion instructions, such as rcp_inequal , which raises a fault when two Arm registers do not contain the same 32-bit value.

The 8-bit tag value in Figure 13 is an 8-bit instruction immediate value encoded by the instruction CRn and CRm fields. These 8-bit values are used to uniquely identify functions for canary value generation so that stack frames are not interchangeable between functions. They also provide 8-bit counter values for rcp_count_set and rcp_count_check instructions. Encoding the tags using the CRn and CRm fields makes RCP instruction sequences more compact, as it obviates additional instructions to materialise these small constants in registers and pass them through CPWDATA. This also makes the tag values less vulnerable to glitching, because the instruction opcode fields are available earlier in the cycle than the register values passed on CPWDATA.

RCP instructions may also execute in the Non-secure state, with certain differences to prevent Non-secure code from triggering RCP faults or observing the value of the salt register. This supports Non-secure software executing shared ROM routines which contain RCP instructions, but does not allow probing of the RCP's internal state from a Non-secure context. Section 3.6.3.2 gives further details and rationale for Non-secure execution support.

Certain details are elided from Figure 13 for clarity, such as the delay counter used for pseudorandom instruction delays, and the logic for suppressing faults under Non-secure execution. This behaviour is described in full in the following sections.

3.6.3.1. Salt register

Each RCP instance is provisioned with a 64-bit salt register , which provides a seed for stack canary values and random instruction delays. This is expected to be initialised with a random value early in the boot process: the RP2350 bootrom uses the true random number generator to generate the salt values.

Initially the salt register is in the invalid state. This state only allows the following operations:

• • Checking the valid state of the salt register, via rcp_canary_status
• • Writing a salt via rcp_salt_core0 or rcp_salt_core1 , which writes a 64-bit value to that core's salt register, and changes its state to valid

When the salt register is in the invalid state, executing any RCP instruction other than those listed above unconditionally triggers an RCP fault . This makes it difficult to skip RCP initialisation via fault injection, because the RP2350 bootrom contains a high density of RCP instructions.

Similarly, attempting to write to an already-valid RCP salt register triggers an RCP fault. There is no reason to initialise the RCP salt register twice, so this case is detected as an anomaly that indicates loss of control flow integrity.

Core 0's coprocessor port writes the salt registers for both cores' RCP instances to simplify multicore interactions during early boot. In the RP2350 bootrom, core 1's first steps lock down its MPU execute permissions to a small region of the ROM containing its wait-for-launch code, and then poll for its RCP salt to become valid once core 0 has cleared boot memory, performed some minimal hardware setup, and generated the RCP salts.

When core 0 is switched to RISC-V architecture and core 1 is Arm, the core 1 salt register is forcibly marked as valid to permit core 1 to execute the ROM. This has no impact on secure boot because RISC-V cores are only enabled when secure boot is disabled; the ability to set core 0 to RISC-V already implies subversion of secure boot.

3.6.3.2. Access from Non-secure

Setting bit 7 of the Cortex-M33 NSACR register permits Non-secure code to set bit 7 of CPACR_NS , which in turn enables Non-secure access to the RCP. Non-secure RCP access is useful for executing shared Secure/Non-secure routines which contain RCP instructions. For example, the memcpy implementation in the RP2350 bootrom is shared by Secure code in the main boot path, and Non-secure code such as the USB bootloader.

Since an RCP fault is fatal for all software running on the system, Non-secure must not be able to trigger RCP faults at will. Similarly, if Non-secure code were able to read out the RCP salt register, it would make it easier to engineer stack payloads which can control Secure execution without triggering RCP faults. Therefore the RCP handles Non-secure accesses differently from Secure:

• • Masks read data to all-zeroes

• • Ignores write data: any instruction which would generate a data-dependent RCP fault becomes a no-op
• • Reports coprocessor errors instead of RCP faults for invalid instructions, which the processor maps to the Non-secure UNDEFINSTR UsageFault
• • Skips the pseudorandom instruction delay: all RCP instructions execute in one cycle, assuming the Cortex-M33 is able to issue them at one instruction per cycle

The lack of pseudorandom instruction delays makes it more difficult for Non-secure code to extract the seed value used to add delays to Secure execution of RCP instructions.

3.6.3.3. Instruction validation

The RCP applies the following rules to all coprocessor instructions which target coprocessor 7:

• • The number of 1 bits in the Opc1 field, plus the instruction parity bit, must be an even number.
  • ◦ For mcr , mrc and cdp instructions, bit 0 of the Opc2 field encodes the parity bit.
  • ◦ For mcr , bit 3 of the CRm field encodes the parity bit.
• • The instruction must not be an mrrc (64-bit coprocessor-to-core)
• • For mcr instructions (32-bit core-to-coprocessor):
  • ◦ The Opc1 field must be in the range 0 through 6.
  • ◦ If there is no 8-bit tag (i.e. any other than rcp_canary_check , rcp_count_check , rcp_count_set ), the CRn and CRm opcode fields must be all-zeroes.
• • For mrc instructions (32-bit coprocessor-to-core):
  • ◦ The Opc1 field must be in the range 0 through 2.
  • ◦ For instructions other than rcp_canary_get and rcp_canary_check , the CRn and CRm opcode fields must be all-zeroes.
• • For mrrc instructions (64-bit core-to-coprocessor):
  • ◦ The Opc1 field must be in the range 0 through 8.
  • ◦ For rcp_salt_core* instructions, bits 2:0 of the CRm field must be 0 or 1 (referred to as rcp_salt_core0 and rcp_salt_core1 respectively).
  • ◦ For all other mrrc instructions, bits 2:0 of the CRm field must be 0.

The terms Opc1 , Opc2 , CRm and CRn in the description above refer to standard encoding fields in the Arm T32 instruction encoding for coprocessor instructions. See the Arm v8-M Architecture Reference Manual for full details of the encoding and assembler syntax.

Any coprocessor instruction targeting coprocessor 7 that fails these validation rules will result in one of two outcomes, depending on the security domain in which the instruction is executed:

• • Secure execution of an invalid instruction is an immediate, unconditional RCP fault. The RCP asserts the core's non-maskable interrupt signal, and any further RCP instructions stall the coprocessor port indefinitely. This continues until the core receives a warm reset. This also triggers RCP faults on other cores: for more information, see Section 3.6.3.4 .
• • Non-secure execution of an invalid instruction returns an error on the opcode-phase coprocessor interface, which is interpreted as a Non-secure UNDEFINSTR UsageFault by the core. For a full description of this Arm v8-M-specific fault, see the Arm v8-M Architecture Reference Manual .

3.6.3.4. Cross-core triggering

An RCP fault indicates that the integrity of the software environment is compromised. Though the fault may originate on

a single processor, all processors which share the same trusted memory may behave unpredictably if they continue to execute, since:

• • The physical condition which caused one processor to misexecute in a detectable way, such as low supply voltage, may cause other processors to misexecute in a manner which was not detected.
• • The processor which triggered an RCP fault may already have corrupted shared, trusted memory contents in a way that interferes with the other processor's operation, (e.g. corrupting the other core's stack).

Therefore, an RCP fault on one core also triggers an RCP fault on other cores. Because RP2350 has two cores, an RCP fault on core 0 always triggers a fault on core 1, and an RCP fault on core 1 always triggers a fault on core 0.

Figure 14. Triggering an RCP fault on one core also triggers a fault on the other core. Triggers accumulate into a fault register, which remains set until the core resets. The NMI asserts when the fault register is set.

Each core locally ORs in the trigger signal from the other core. The outputs of the two OR gates on the left are logically equivalent, but the gates are kept local to the core to minimise delay routing the core's own fault trigger to its own fault register.

3.6.3.5. Stack canary values

Canaries are values written to the stack on function entry and validated on function exit, to assure that:

• • The exit matches the entry (i.e. when leaving through the back door, you entered through the front door)
• • The stack was not completely overwritten in the course of executing the function

This helps to mitigate two classes of attack:

• • Fault injection: any physical fault condition which corrupts the program counter or causes a wild indirect branch is likely to cause the processor to execute a function epilogue which does not match the prologue. Any branch into the middle of a function is likely to eventually reach the epilogue.
• • Return-oriented programming: deliberate stack corruption can redirect control flow through a sequence of function tails which perform arbitrary operations. The stack may be corrupted by exploiting missing bounds checks on stack buffer operations. Random canary values make it difficult to craft such a stack payload.

Return-oriented programming mitigation is particularly important to account for in the bootrom because the bootrom exposes an API surface that is mapped at a known location at runtime (it is physically always mapped at 0x00000000 ). This provides a well-known exploit surface similar to the C standard library.

The RCP supports canary values with two canary-specific instructions:

• • rcp_canary_get generates a 32-bit value for an 8-bit tag as a function of the salt register
• • rcp_canary_check validates a 32-bit value for an 8-bit tag and raises an RCP fault if the value does not match that produced by an rcp_canary_get for the same tag.

The 32-bit canary value is as follows:

• • Bits 7:0: all-zero
• • Bits 15:8: XOR of bits 7:0 of the salt with (AND of bits 31:24 of the salt with the 8-bit tag)

• • Bits 23:16: XOR of bits 15:8 of the salt with (AND of bits 39:32 of the salt with the bitwise NOT of the 8-bit tag)
• • Bits 31:24: XOR of bits 23:16 of the salt with the 8-bit tag

The following code demonstrates how you might calculate the 32-bit canary value in C:

uint32_t canary_value(uint64_t salt, uint8_t tag) {
    uint32_t tag_expanded =
        ((uint32_t)tag |
         ((uint32_t)~tag << 8)
         ((uint32_t)tag << 16));
    tag_expanded &= (0xff0000u | ((salt >> 24) & 0x00ffffu));
    uint32_t result24 = tag_expanded ^ salt;
    return result24 << 8;
}

This canary value is chosen such that:

• • Different tags are guaranteed to yield different canary values
• • For any two different tags, each is a function of at least one salt bit that the other is not a function of (so it is difficult to calculate canaries for different tags even if one value is known)
• • Null-terminated string operations on the stack terminate before reading or writing a canary

Each function should use a different canary tag, to prevent a stack frame for one function being used to return through another function's epilogue. Avoid using canary values for purposes other than stack canaries.

The RP2350 bootrom uses 8-bit tags in the range 0x40 through 0xbf. The remaining tags are free for use in user code.

3.6.3.6. Pseudorandom instruction delays

By default, all RCP instructions execute with a pseudorandom delay in the range of 0 to 127 cycles. These delays make it more difficult for an outside observer to precisely time a fault injection event with respect to an RCP instruction, or the critical code path it protects.

i NOTE

In certain usage situations, RCP delays can expose a side-channel where processor state can be inferred. See RP2350-E26 for details.

Setting bit 12 of the first halfword of an instruction disables the pseudorandom delay for that instruction only. The instruction executes in a single cycle, assuming the Cortex-M33 does not insert stall cycles due to other micro-architectural constraints. To set this bit, assemble the *2 variant of any given coprocessor instruction (e.g. mrc2 rather than mrc ). In the NonSecure state, RCP instructions always execute without delay.

The RCP implements instruction execution delays by stalling the coprocessor opcode interface during the opcode phase (shown in the Figure 13 pipeline diagram). The Cortex-M33 may choose to abandon a stalled coprocessor instruction due to an interrupt. When this happens, the delay counter continues counting down, waiting for the delay period to elapse. If the Cortex-M33 issues another RCP instruction whilst the delay counter is still running (either in the interrupt, or after returning to the interrupted RCP instruction), this instruction executes once the existing countdown completes. However, if the delay counter of an abandoned instruction has already expired before the next RCP instruction executes, the next instruction samples a pseudorandom delay count, and begins a new countdown.

The pseudorandom delay sequence is a function of bits 63:40 of the salt value. As such, the pattern of delays is unique per-boot, provided each boot writes a different 64-bit value to the salt register.

The pseudorandom number generator (PRNG) used for delays implements a number of small linear feedback shift registers (LFSRs) in bits 63:40 of the salt register, and returns a nonlinear function of the 24-bit state. The LFSR feedback functions on the 24-bit state are:

• • Bits 23:20: 4-bit LFSR with taps 0xc
• • Bits 19:15: 5-bit LFSR with taps 0x14
• • Bits 14:8: 7-bit LFSR with taps 0x60
• • Bits 7:0: 8-bit LFSR with taps 0xb4

The LFSRs are implemented by shifting the XOR reduction of (state AND taps) into the LSB with each state update. When an LFSR's state is all-zeroes, a one bit is shifted into the LSB. The LFSR state advances each time a random number is generated: this happens when executing an instruction with a pseudorandom delay, or when executing a rcp_random_byte instruction.

Each bit of the pseudorandom output is the XOR of six bits of the 24-bit state, XORed with the majority-3 vote of three other bits of the state:

Bits 6:0 of this function are used for pseudorandom instruction delays, producing delays in the range of 0 to 127 cycles. The delay is applied in addition to the one-cycle base cost of executing a coprocessor instruction. The full 8-bit result is available through the rcp_random_byte instruction.

This is a simple pseudorandom number generator which makes it difficult to recover the initial 24-bit state from a small number of observations. It accomplishes this by making the observation size much smaller than the state size and using a non-linear combination function for the output. It has a number of statistical aberrations which make it unsuitable for general random number generation (not to mention its small state size). For high-quality random number generation, either use the system true-random number generator (TRNG) directly, or use a high-quality software PRNG with a large state seeded from the TRNG.

Note that the 24 MSBs of the salt value used to seed the delay PRNG do not overlap with the 40 LSBs used to generate stack canary values. Therefore measuring the random delays externally provides no information on the canary values.

3.6.3.7. Instruction listing

The Cortex-M33 processors access the RCP using mcr , mcrf , mrc , and cdp instructions. The Armv8-M Architecture Reference Manual describes the intricacies of these instructions in relation to the processor's architectural state, but from the coprocessor's point of view:

• • mcr writes a 32-bit value to the coprocessor from a single Arm integer register
• • mcrf writes a 64-bit value to the coprocessor from a pair of Arm integer registers
• • mrc reads a 32-bit value from the coprocessor, writing to either a single Arm integer register or to the processor status flags
• • cdp performs some internal coprocessor operation without exchanging data with the processor

For each mcr , mcrf , mrc and cdp instruction, the RCP also accepts the matching mcr2 , mcrf2 , mrc2 , and cdp2 opcode variant. These opcodes differ only in bit 12. The plain versions have a pseudorandom delay of up to 127 cycles on their

execution, whereas the 2 -suffixed versions have no such delay.

Most RCP instructions are in the form of hardware-checked assertions. The phrase "asserts that" in the following instruction listings means that, if some asserted condition is not true, the coprocessor raises an RCP fault.

3.6.3.7.1. Initialisation

rcp_salt_core0

Asserts that the core 0 salt register is currently invalid. Writes a 64-bit value, and marks it as valid.

Opcode:

mrrr p7, #8, Rt, Rt2, c0

Rt is the 32 LSBs of the salt, Rt2 is the 32 MSBs.

rcp_salt_core1

Asserts that the core 1 salt register is currently invalid. Writes a 64-bit value, and marks it as valid.

Opcode:

mrrr p7, #8, Rt, Rt2, c1

rcp_canary_status

Returns a true or false bit pattern ( 0xa500a500 or 0xc300c300 respectively) that indicates whether the salt register for this core has been initialised.

Opcode:

mrc p7, #1, Rt, c0, c0, #0

Invoking with Rt = 0xf sets the Arm N and C flags if and only if the salt register is valid.

If the salt has not been initialised, any operation other than initialising the salt or checking the canary status triggers an RCP fault.

This opcode is used on core 0 to skip the RCP initialisation sequence if the bootrom has been re-entered without a reset under debugger control, and on core 1 to wait for its RCP salt to be initialised.

3.6.3.7.2. Canary

rcp_canary_get

Gets a 32-bit canary value as a function of the salt register and the 8-bit tag encoded by two 4-bit coprocessor register numbers CRn and CRm . CRn contains the four MSBs, CRm the four LSBs.

Opcode:

mrc p7, #0, Rt, CRn, CRm, #1

Section 3.6.3.5 specifies the 32-bit value returned by this instruction, but you should treat this as an opaque value to be consumed by rcp_canary_check .

Asserts that a value matches the result of an rcp_canary_get with the same 8-bit tag. The tag is encoded by two 4-bit coprocessor register numbers, CRn and CRm . CRn contains the four MSBs, CRm the four LSBs.

Opcode:

mcr p7, #0, Rt, CRn, CRm, #1

The RCP defines 0xa500a500 as the true value for 32-bit booleans, and 0x00c300c3 as the false value. All other bit patterns are poison, and trigger an RCP fault when consumed by any RCP boolean instructions. These values are chosen as they are valid immediates in Armv8-M Main.

This provides limited runtime type checking to ensure that boolean values are used in boolean contexts. The RP2350 bootrom occasionally uses redundant operations to generate booleans in a way that results in an invalid bit pattern if the two redundant operations do not return the same value, such as when checking boot flags in OTP.

Asserts that Rt is a valid boolean ( 0xa500a500 or 0x00c300c3 ).

Opcode:

mcr p7, #1, Rt, c0, c0, #0

Asserts that Rt is true ( 0xa500a500 ).

Opcode:

mcr p7, #2, Rt, c0, c0, #0

Asserts that Rt is false ( 0x00c300c3 ).

Opcode:

mcr p7, #3, Rt, c0, c0, #1

Asserts that Rt and Rt2 are both valid booleans.

Opcode:

mcr p7, #0, Rt, Rt2, c8

Asserts that Rt and Rt2 are both true .

Opcode:

mrrr p7, #1, Rt, Rt2, c0

Asserts that both Rt and Rt2 are valid, and at least one is true .

mrrr p7, #2, Rt, Rt2, c0

Asserts that Rt XOR Rt2 is a valid boolean. The XOR mask is generally a fixed bit pattern used to validate the origin of the boolean, such as a return value from a critical function.

Opcode:

mrrr p7, #3, Rt, Rt2, c8

Asserts that Rt XOR Rt2 is true .

Opcode:

mrrr p7, #4, Rt, Rt2, c0

Asserts that Rt XOR Rt2 is false .

Opcode:

mrrr p7, #5, Rt, Rt2, c8

Asserts that Rt XOR Rt2 is equal to 0x96009600 . This is used to validate 32-bit integers stored redundantly in two memory words. The XOR difference provides assurance that two parallel chains of integer operations have not mixed.

Opcode:

mcr p7, #6, Rt, Rt2, c8

rcp_inequal

Asserts that Rt is equal to Rt2 . Useful for general software assertions that are worth checking in hardware.

Opcode:

mcr p7, #7, Rt, Rt2, c0

3.6.3.7.5. Random

rcp_random_byte

Returns a random 8-bit value generated from the upper 24 bits of the 64-bit salt value. Bits 31:8 of the result are all-zero.

Opcode:

mrc p7, #2, Rt, c0, c0, #0

This is the same PRNG used for random delay values. It is mainly exposed for debugging purposes, and should not be used for general software RNG purposes because the 24-bit state space is inadequate for scenarios where the quality and predictability of the random numbers is important.

This instruction never has an execution delay. Once the Cortex-M33 issues the coprocessor access, it always completes in one cycle.

3.6.3.7.6. Sequence count checking

These instructions are used to assert that a sequence of operations happens in the correct order. The count is initialised to an 8-bit value at the beginning of such a sequence, then repeatedly checked, incrementing with each check. If the 8-bit check value does not match the current counter value, the coprocessor raises an RCP fault.

rcp_count_set

Writes an 8-bit count value to the RCP sequence counter. Encodes the 8-bit value using two 4-bit coprocessor numbers: CRn provides the MSBs, CRm the LSBs.

Opcode:

mcr p7, #4, r0, CRn, CRm, #0

rcp_count_check

Asserts that an 8-bit count value matches the current value of the RCP sequence counter. Increments the counter by one, wrapping back to 0x00 after reaching 0xff . Encodes the 8-bit count value using two 4-bit coprocessor numbers: CRn provides the MSBs, CRm the LSBs.

Opcode:

mcr p7, #5, r0, CRn, CRm, #1

3.6.3.7.7. Panic

rcp_panic

Stalls the coprocessor port forever. If the processor abandons the coprocessor access, asserts NMI and continues stalling the coprocessor port. Also immediately raises an RCP fault on other cores.

Opcode:

cdp p7, #0, c0, c0, c0, #1

Software executes an rcp_panic instruction when it detects a condition that makes it unsafe to continue executing the current program. The RCP responds by stalling the processor's CDP access forever, which should cause the processor to stop fetching and executing instructions.

The processor is allowed to abandon a stalled coprocessor instruction when interrupted, which may cause it to continue executing in an unsafe state. The RCP responds to an abandoned transfer by asserting the non-maskable interrupt, pre-empting the interrupt handler that caused the coprocessor access to be abandoned. This should swiftly encounter another RCP instruction and once again stall the processor, this time without allowing interruption.

Panic is specified in this way, instead of gating the processor clock, so the debugger can still attach cleanly to the processor after a panic.

3.6.4. Floating point unit

The Cortex-M33 cores on RP2350 are configured with the standard Arm single-precision floating point unit (FPU). Coprocessor ports 10 and 11 access the FPU.

The Arm floating point extension is documented in the Armv8-M Architecture Reference Manual .

Applications built with the SDK use the FPU automatically by default. For example, calculations with the float data type in C automatically use the standard FPU, while calculations with the double data type automatically use the RP2350 double-precision coprocessor ( Section 3.6.2 ).

3.7. Cortex-M33 processor

Arm Documentation

Much of the following is excerpted from the Cortex-M33 Technical Reference Manual . Used with permission.

The Arm Cortex-M33 processor is a low gate count, highly energy-efficient processor intended for microcontroller and embedded applications. The processor is based on the Armv8-M architecture and is primarily for use in environments where security is an important consideration.

Full details of the Arm Cortex-M33 processor can be found in the Technical Reference Manual .

3.7.1. Features

The Arm Cortex-M33 processor provides the following features and benefits:

• • An in-order issue pipeline
• • Thumb-2 technology; for more information, see the Armv8-M Architecture Reference Manual
• • Little-endian data accesses
• • A Nested Vectored Interrupt Controller (NVIC) closely integrated with the processor
• • A Floating Point Unit (FPU) supporting single-precision arithmetic
• • Support for exception-continuable instructions, such as LDM, LDMDB, STM, STMDB, PUSH, POP, VLDM, VSTM, VPUSH, and VPOP
• • A low-cost debug solution that provides the ability to implement:
  • ◦ Breakpoints
  • ◦ Watchpoints
  • ◦ Tracing
  • ◦ System profiling
  • ◦ Support for printf() style debugging through an Instrumentation Trace Macrocell (ITM)
• • Support for the Embedded Trace Macrocell (ETM) instruction trace option; for more information, see the Arm CoreSight ETM-M33 Technical Reference Manual
• • A coprocessor interface for external hardware accelerators
• • Low-power features including architectural clock gating, sleep mode, and a power-aware system with Wake-up Interrupt Controller (WIC)
• • A memory system that includes memory protection and security attribution

3.7.2. Configuration

Each Arm Cortex-M33 processor in RP2350 is configured with the following features:

• • FPU : Single precision FPU
• • DSP : DSP extension
• • SECEXT : Security extensions
• • CPIF : coprocessor interface
• • MPU_NS : 8 non-secure MPU regions
• • MPU_S : 8 secure MPU regions
• • SAU : 8 SAU regions
• • IRQ : 52 external interrupts
• • IRQLVL : 4 exception priority bits
• • DBGLVL : Full debug set: 4 watchpoint, 8 breakpoint comparators, debug monitor

• • ITM: DWT and ITM trace
• • ETM : ETM trace
• • MTB : no MTB trace
• • WIC: Wake up interrupt controller
• • WICLINES: 55: All external interrupts and 3 internal events: NMI, RVEX, Debug
• • CTI : Cross trigger interface
• • RAR: reset all registers on power up
• • UNCROSS_I_D : Modify internal address map
• • SBIST: no SBIST features
• • CDE modules not used
• • CDERTLID: RTL ID for system with multi Cortex-M33: 16

Architectural clock gating allows the processor core to support SLEEP and DEEPSLEEP power states by disabling the clock to parts of the processor core. Power gating is not supported.

Each Cortex-M33 core has its own interrupt controller that can individually mask out interrupt sources as required. The same interrupts route to both Cortex-M33 cores.

The processor supports the following interfaces:

• • Code AHB (C-AHB) interface
• • System AHB (S-AHB) interface
• • External PPB (EPPB) APB interface
• • Debug AHB (D-AHB) interface

The processor implements the following optional interfaces:

• • Arm TrustZone technology, using the Armv8-M Security Extension supporting Secure and Non-secure states
• • Memory Protection Units (MPUs), which you can configure to protect regions of memory
• • Floating-point arithmetic functionality with support for single precision arithmetic
• • Support for ETM trace

3.7.2.1. Modifications by Raspberry Pi

3.7.2.1.1. UNCROSS_I_D

The original Cortex-M33 processor design routes the following operations to either the Code or System port:

• • instruction fetch
• • load/stores
• • debugger accesses

Accesses below address 0x20000000 route to the Code port. All other accesses route to the System port.

This routing strategy makes contention possible on both the internal bus matrix and the main system AHB5 crossbar. The Cortex-M33 Technical Reference Manual describes this strategy in detail.

In RP2350, Raspberry Pi modified the Cortex-M33 bus matrix to:

• • route all instruction fetch operations to the Code port

• • route all load/stores and debugger accesses to the System port

This eliminates internal conflicts and improves performance in certain software use cases, e.g. when allocating both code and data from a single unified SRAM pool.

In Section 3.7.2 , we refer to this feature as UNCROSS_I_D .

There are no other modifications to the Cortex-M33 processor.

NOTE

This datasheet may refer to the Cortex-M33 Code and System ports as the instruction and data ports respectively (I and D), to reflect this modification to the core's integrated bus matrix.

3.7.2.2. Interfaces

The processor has various external interfaces:

Code and System AHB interfaces

Harvard AHB bus architecture supporting exclusive transactions and security state.

System AHB interface

The System AHB (S-AHB) interface is used for any instruction fetch and data access to the memory-mapped SRAM, Peripheral, External RAM and External device, or Vendor_SYS regions of the Armv8-M memory map.

Code AHB interface

The Code AHB (C-AHB) interface is used for any instruction fetch and data access to the Code region of the Armv8-M memory map.

External Private Peripheral Bus

The External PPB (EPPB) APB interface enables access to CoreSight-compatible debug and trace components in a system connected to the processor.

Secure attribution interface

The processor has an interface that connects to an external Implementation Defined Attribution Unit (IDAU), which enables your system to set security attributes based on address.

ATB interfaces

The ATB interfaces output trace data for debugging. The ATB interfaces are compatible with the CoreSight architecture. See the Arm CoreSight Architecture Specification v2.0 for more information. The instruction ATB interface is used by the ETM, and the instrumentation ATB interface is used by the Instrumentation Trace Macrocell (ITM).

Micro Trace Buffer interfaces

The Micro Trace Buffer (MTB) AHB slave interface and SRAM interface are for the CoreSight Micro Trace Buffer.

Coprocessor interface

The coprocessor interface is designed for closely coupled external accelerator hardware.

Debug AHB interface

The Debug AHB (D-AHB) slave interface allows a debugger access to registers, memory, and peripherals. The D-AHB interface provides debug access to the processor and the complete memory map.

Cross Trigger Interface

The processor includes a Cross Trigger Interface (CTI) Unit that has an interface that is suitable for connection to external CoreSight components using a Cross Trigger Matrix (CTM).

Power control interface

The processor supports a number of internal power domains that can be enabled and disabled using Q-channel interfaces connected to a Power Management Unit (PMU) in the system.

3.7.2.3. Security attribution and memory protection

The Cortex-M33 processor supports the Armv8-M Protected Memory System Architecture (PMSA) that provides programmable support for memory protection using a number of software controllable regions. RP2350 supports 8 programmable regions.

PMSA allows privileged software to assign access permissions to a memory region. When unprivileged software attempts to access the region, a fault exception is triggered. PMSA includes fault status registers that allow an exception handler to determine the source of the fault, apply corrective action, and notify the system. This reduces the potential impact of incorrectly-written application code.

The Cortex-M33 processor also includes support for defining memory regions as Secure or Non-secure, as defined in the Armv8-M Security Extension. This protects memory regions from accesses with an inappropriate level of security.

3.7.2.4. Floating-point unit (FPU)

The FPU provides:

• • Instructions for single-precision (C programming language float type) data-processing operations
• • Instructions for double-precision (C programming language double type) load and store operations
• • Combined multiply-add instructions for increased precision (Fused MAC)
• • Hardware support for conversion, addition, subtraction, multiplication, accumulate, division, and square-root
• • Hardware support for denormals and all IEEE Standard 754-2008 rounding modes
• • Thirty-two 32-bit single-precision registers or sixteen 64-bit double-precision registers
• • Lazy floating-point context save

3.7.2.4.1. Lazy floating-point context save

This FPU function delays automated stacking of floating-point state until the ISR attempts to execute a floating-point instruction. This reduces the latency to enter the ISR and removes floating-point context save for ISRs that do not use floating-point.

3.7.2.5. NVIC

The Nested Vectored Interrupt Controller NVIC prioritizes external interrupt signals. Software can set the priority of each interrupt. The NVIC and the Cortex-M33 processor core are closely coupled, providing low latency interrupt processing and efficient processing of late arriving interrupts.

i NOTE

"Nested" refers to the fact that interrupts can themselves be interrupted, by higher-priority interrupts. "Vectored" refers to the hardware dispatching each interrupt to a distinct handler routine specified by a vector table. For more details about nesting and vectoring behaviour, see the Armv8-M Architecture Reference Manual .

All NVIC registers are only accessible using word transfers. Any attempt to read or write a halfword or byte individually is unpredictable.

NVIC registers are always little-endian.

The Nested Vectored Interrupt Controller (NVIC) is closely integrated with the core to achieve low-latency interrupt processing.

Functions of the NVIC include:

• • External interrupts, configurable from 1 to 480 using a contiguous or non-contiguous mapping. This is configured at implementation.
• • Configurable levels of interrupt priority from 8 to 256. This is configured at implementation.
• • Dynamic reprioritisation of interrupts.
• • Priority grouping. This enables selection of pre-empting interrupt levels and non-pre-empting interrupt levels.
• • Support for tail-chaining and late arrival of interrupts. This enables back-to-back interrupt processing without the overhead of state saving and restoration between interrupts.
• • Support for the Armv8-M Security Extension. Secure interrupts can be prioritized above any Non-secure interrupt.

3.7.2.6. Cross Trigger Interface Unit (CTI)

The CTI enables the debug logic, MTB, and ETM to interact with each other and with other CoreSight™ components.

3.7.2.7. ETM

The ETM provides instruction-only capabilities.

3.7.2.8. MTB

The MTB provides a simple low-cost execution trace solution for the Cortex-M33 processor.

Trace is written to an SRAM interface, and can be extracted using a dedicated AHB slave interface (M-AHB) on the processor. The MTB can be controlled by memory-mapped registers in the PPB region or by events generated by the DWT or through the CTI.

See the Arm CoreSight MTB-M33 Technical Reference Manual for more information.

3.7.2.9. Debug and trace

Debug and trace components include a configurable Breakpoint Unit (BPU) used to implement breakpoints and a configurable Data Watchpoint and Trace (DWT) unit used to implement watchpoints, data tracing, and system profiling. Other debug and trace components include:

• • ITM for support of printf() style debugging, using instrumentation trace
• • Interfaces suitable for:
  • ◦ Passing on-chip data through a Trace Port Interface Unit (TPIU) to a Trace Port Analyzer (TPA) via a 4-bit DDR output selected as a GPIO function (see Section 3.5.7 )
  • ◦ A ROM table to allow debuggers to determine which components are implemented in the Cortex-M33 processor
  • ◦ Debugger access to all memory and registers in the system, including access to memory-mapped devices, access to internal core registers when the core is halted, and access to debug control registers even when reset is asserted

3.7.3. Compliance

The processor complies with, or implements, the relevant Arm architectural standards and protocols, and relevant external standards.

3.7.3.1. Arm architecture

The processor is compliant with the following:

• • Armv8-M Main Extension
• • Armv8-M Security Extension
• • Armv8-M Protected Memory System Architecture (PMSA)
• • Armv8-M Floating-point Extension
• • Armv8-M Digital Signal Processing (DSP) Extension
• • Armv8-M Debug Extension
• • Armv8-M Flash Patch Breakpoint (FPB) architecture version 2.0

3.7.3.2. Bus architecture

The processor provides external interfaces that comply with the AMBA 5 AHB5 protocol. The processor also implements interfaces for CoreSight and other debug components using the APB4 protocol and ATBv1.1 part of the AMBA 4 ATB protocol.

For more information, see the:

• • Arm AMBA 5 AHB Protocol Specification
• • AMBA APB Protocol Version 2.0 Specification
• • Arm AMBA 4 ATB Protocol Specification ATBv1.0 and ATBv1.1

The processor also provides a Q-Channel interface. For more information, see the AMBA Low Power Interface Specification .

3.7.3.3. Debug

The debug features of the processor implement the Arm Debug Interface Architecture. For more information, see the Arm Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2 .

3.7.3.4. Embedded Trace Macrocell

The trace features of the processor implement the Arm Embedded Trace Macrocell (ETM) v4.2 architecture.

For more information, see the Arm CoreSight ETM-M33 Technical Reference Manual .

3.7.3.5. Floating-point unit

The Cortex-M33 processor with FPU supports single-precision arithmetic as defined by the FPv5 architecture that is part of the Armv8-M architecture. The FPU provides floating-point computation functionality compliant with ANSI/IEEE Standard 754-2008, IEEE Standard for Binary Floating-Point Arithmetic.

The FPU supports single-precision add, subtract, multiply, divide, multiply and accumulate, and square root operations. It also provides conversions between fixed-point and floating-point data formats, and floating-point constant instructions.

The FPU provides an extension register file containing 32 single-precision registers.

The registers can be viewed as:

• • Thirty-two 32-bit single-word registers, S0-S31
• • Sixteen 64-bit double-word registers, D0-D15
• • A combination of registers from these views

3.7.3.5.1. FPU modes

The FPU provides full-compliance, flush-to-zero, and Default NaN modes of operation. In full-compliance mode, the FPU processes all operations according to the IEEE 754 standard in hardware.

Modes of operation are controlled using the Floating-Point Status and Control Register, FPSCR .

Setting the FPSCR.FZ bit enables Flush-to-Zero (FZ) mode. In FZ mode, the FPU treats all subnormal input operands of arithmetic operations as zeros. Exceptions that result from a zero operand are signalled appropriately. VABS , VNEG , and VMOV are not considered arithmetic operations and are not affected by FZ mode. When an operation yields a tiny result (as described in the IEEE 754 standard, where the destination precision is smaller in magnitude than the minimum normal value before rounding) FZ mode replaces the result with a zero.

The FPSCR.IDC bit indicates when an input flush occurs.

The FPSCR.UFC bit indicates when a result flush occurs.

Setting the FPSCR.DN bit enables Default NaN (DN) mode. In NaN mode, the result of any arithmetic data processing operation that involves an input NaN, or that generates a NaN result, returns the default NaN. All arithmetic operations except for VABS , VNEG , and VMOV ignore the fraction bits of an input NaN.

Setting neither the FPSCR.DN bit nor the FPSCR.FZ bit enables full-compliance mode. In full-compliance mode, FPv5 functionality is compliant with the IEEE 754 standard in hardware.

For more information about the FPU and FPSCR , see the Armv8-M Architecture Reference Manual .

3.7.3.5.2. FPU exceptions

The FPU sets the cumulative exception status flag in the FPSCR register as required for each instruction, in accordance with the FPv5 architecture. The FPU does not support exception traps.

The processor has six output pins. By default, they are disconnected. Each reflect the status of one of the cumulative exception flags:

FPIXC

Masked floating-point inexact exception.

FPUFC

Masked floating-point underflow exception.

FPOFC

Masked floating-point overflow exception.

FPDZC

Masked floating-point divide by zero exception.

FPIDC

Masked floating-point input denormal exception.

FPIOC

Invalid operation.

When a floating-point context is active, the stack frame extends to accommodate the floating-point registers. To reduce the additional interrupt latency associated with writing the larger stack frame on exception entry, the processor supports lazy stacking. This means that the processor reserves space on the stack for the FP state, but does not save that state information to the stack unless the processor executes an FPU instruction inside the exception handler.

The lazy save of the FP state is interruptible by a higher priority exception. The FP state saving operation starts over after that exception returns.

3.7.3.5.3. Low power FPU operation

If the FPU is in a separate power domain, the way the FPU domain powers down depends on whether the FPU domain includes state retention logic.

To power down the FPU:

• • If FPU domain includes state retention logic, disable the FPU by clearing the CPACR.CP10 and CPACR.CP11 bitfields.
• • If FPU domain does not include state retention logic, disable the FPU by clearing the CPACR.CP10 and CPACR.CP11 bitfields and set both the CPPWR.SU10 and CPPWR.SU11 bitfields to 1.

WARNING

Setting the CPPWR.SU10 and CPPWR.SU11 bitfields indicates that FPU state can be lost.

3.7.4. Programmer's model

The Cortex-M33 programmer's model is an implementation of the Armv8-M Main Extension architecture.

For a complete description of the programmers model, refer to the Armv8-M Architecture Reference Manual , which also contains the Armv8-M Thumb instructions. In addition, other options of the programmers model are described in the System Control, MPU, NVIC, FPU, Debug, DWT, ITM, and TPIU feature topics.

3.7.4.1. Modes of operation and execution

The Cortex-M33 processor supports Secure and Non-secure security states, Thread and Handler operating modes, and can run in either Thumb or Debug operating states. In addition, the processor can limit or exclude access to some resources by executing code in privileged or unprivileged mode.

See the Armv8-M Architecture Reference Manual for more information about the modes of operation and execution.

3.7.4.1.1. Security states

With the Armv8-M Security Extension, the programmer's model includes two orthogonal security states: Secure state and Non-secure state. The processor always resets into Secure state. Each security state includes a set of independent operating modes and supports both privileged and unprivileged user access. Registers in the System Control Space are banked across Secure and Non-secure state, with a Non-secure register view available to Secure state at an aliased address.

3.7.4.1.2. Operating modes

For each security state, the processor can operate in Thread or Handler mode. The following conditions cause the processor to enter Thread or Handler mode:

• • The processor enters Thread mode on reset, or as a result of an exception return to Thread mode. Privileged and Unprivileged code can run in Thread mode.
• • The processor enters Handler mode as a result of an exception. In Handler mode, all code is privileged.

The processor can change security state on taking an exception, for example when a Secure exception is taken from Non-secure state, the Thread mode enters the Secure state Handler mode. The processor can also call Secure functions

from Non-secure state and Non-secure functions from Secure state. The Security Extension includes requirements for these calls to prevent Secure data from being accessed in Non-secure state.

3.7.4.1.3. Operating states

The processor can operate in Thumb or Debug state:

• • Thumb state is the state of normal execution running 16-bit and 32-bit halfword- aligned Thumb instructions.
• • Debug state is the state when the processor is in Halting debug.

3.7.4.1.4. Privileged access and unprivileged user access

Code can execute as privileged or unprivileged. Unprivileged execution limits resource access appropriate to the current security state. Privileged execution has access to all resources available to the security state. Handler mode is always privileged. Thread mode can be privileged or unprivileged.

3.7.4.2. Instruction set summary

The processor implements the following instruction from Armv8-M:

• • All base instructions
• • All instructions in the Main Extension
• • All instructions in the Security Extension
• • All instructions in the DSP Extension
• • All single-precision instructions and double precision load/store instructions in the Floating-point Extension

For more information about Armv8-M instructions, see the Armv8-M Architecture Reference Manual .

3.7.4.3. Memory model

The processor contains a bus matrix that arbitrates instruction fetches and memory accesses from the processor core between the external memory system and the internal System Control Space (SCS) and debug components.

Priority is usually given to the processor to keep debug accesses as non-intrusive as possible.

The system memory map is Armv8-M Main Extension compliant, and is common both to the debugger and processor accesses.

The default memory map provides user and privileged access to all regions except for the Private Peripheral Bus (PPB). The PPB space only allows privileged access.

The following table shows the default memory map. This is the memory map used when the included MPUs are disabled. The attributes and permissions of all regions, except that targeting the NVIC and debug components, can be modified using an implemented MPU.

Table 114. Default memory map

The internal Secure Attribution Unit (SAU) determines the security level associated with an address. Some internal peripherals have memory-mapped registers in the PPB region which are banked between Secure and Non-secure state. When the processor is in Secure state, software can access both the Secure and Non-secure versions of these registers. The Non-secure versions are accessed using an aliased address.

For more information about the memory model, see the Armv8-M Architecture Reference Manual .

3.7.4.3.1. Private Peripheral Bus (PPB)

The Private Peripheral Bus (PPB) memory region provides access to internal and external processor resources.

The internal PPB provides access to:

• • The System Control Space (SCS), including the Memory Protection Unit (MPU), Secure Attribution Unit (SAU), and the Nested Vectored Interrupt Controller (NVIC).
• • The Data Watchpoint and Trace (DWT) unit.
• • The Breakpoint Unit (BPU).
• • The Embedded Trace Macrocell (ETM).
• • CoreSight Micro Trace Buffer (MTB).
• • Cross Trigger Interface (CTI).
• • The ROM table.

The external PPB (EPPB) provides access to implementation-specific external areas of the PPB memory map.

3.7.4.3.2. Unaligned accesses

The Cortex-M33 processor supports unaligned accesses. They are converted into two or more aligned AHB transactions on the C-AHB or S-AHB master ports on the processor.

Unaligned support is only available for load/store singles (LDR, LDRH, STR, STRH, TBH) to addresses in Normal memory. Load/store double and load/store multiple instructions already support word aligned accesses, but do not permit other unaligned accesses, and generate a fault if this is attempted. Unaligned accesses in Device memory are not permitted and fault. Unaligned accesses that cross memory map boundaries are architecturally UNPREDICTABLE .

NOTE

If CCR.UNALIGN_TRP for the current Security state is set, any unaligned accesses generate a fault.

3.7.4.4. Exclusive monitor

The Cortex-M33 processor implements a local exclusive monitor. The local monitor within the processor has been constructed so that it does not hold any physical address, but instead treats any store-exclusive access as matching the address of the previous load-exclusive. This means that the implemented exclusives reservation granule is the entire memory address range. For more information about semaphores and the local exclusive monitor, see the Armv8-M Architecture Reference Manual .

3.7.4.5. Processor core registers summary

The following table shows the processor core register set summary. Each of these registers is 32 bits wide. When the Armv8-M Security Extension is included, some of the registers are banked. The Secure view of these registers is available when the Cortex-M33 processor is in Secure state and the Non-secure view when Cortex-M33 processor is in Non-secure state.

Table 115. Processor core register set summary

3.7.4.6. Exceptions

Exceptions are handled and prioritized by the processor and the NVIC. In addition to architecturally defined behaviour, the processor implements advanced exception and interrupt handling that reduces interrupt latency and includes implementation defined behaviour.

The processor core and the Nested Vectored Interrupt Controller (NVIC) together prioritize and handle all exceptions. When handling exceptions:

• • All exceptions are handled in Handler mode.
• • Processor state is automatically stored to the stack on an exception, and automatically restored from the stack at the end of the Interrupt Service Routine (ISR).
• • The vector is fetched in parallel to the state saving, enabling efficient interrupt entry.

The processor supports tail-chaining that enables back-to-back interrupts without the overhead of state saving and restoration.

Software can choose only to enable a subset of the configured number of interrupts, and can choose how many bits of the configured priorities to use.

Exceptions can be specified as either Secure or Non-secure. When an exception occurs the processor switches to the associated security state. The priority of Secure and Non-secure exceptions can be programmed independently. You can deprioritise Non-secure configurable exceptions using the AIRCR.PRIS bit field to enable Secure interrupts to take priority.

When taking and returning from an exception, the register state is always stored using the stack pointer associated with the background security state. When taking a Non-secure exception from Secure state, all the register state is stacked and then registers are cleared to prevent Secure data being available to the Non-secure handler. The vector base

address is banked between Secure and Non-secure state. VTOR_S contains the Secure vector base address, and VTOR_NS contains the Non-secure vector base address. These registers can be programmed by software, and also initialized at reset by the system.

NOTE

Vector table entries are compatible with interworking between Arm and Thumb instructions. This causes bit[0] of the vector value to load into the Execution Program Status Register (EPSR) T-bit on exception entry. All populated vectors in the vector table entries must have bit[0] set. Creating a table entry with bit[0] clear generates an INVSTATE fault on the first instruction of the handler corresponding to this vector.

3.7.4.7. Security attribution and memory protection

Security attribution and memory protection in the processor is provided by the Security Attribution Unit (SAU) and the Memory Protection Units (MPUs).

The SAU is a programmable unit that determines the security of an address. RP2350 includes 8 memory regions.

For instructions and data, the SAU returns the security attribute that is associated with the address.

For instructions, the attribute determines the allowable Security state of the processor when the instruction is executed. It can also identify whether code at a Secure address can be called from Non-secure state.

For data, the attribute determines whether a memory address can be accessed from Non-secure state, and also whether the external memory request is marked as Secure or Non-secure.

If a data access is made from Non-secure state to an address marked as Secure, then a SecureFault exception is taken by the processor. If a data access is made from Secure state to an address marked as Non-secure, then the associated memory access is marked as Non-secure.

The security level returned by the SAU is a combination of the region type defined in the internal SAU, if configured, and the type that is returned on the associated Implementation Defined Attribution Unit (IDAU). If an address maps to regions defined by both internal and external attribution units, the region of the highest security level is selected.

The register fields SAU_CTRL.EN and SAU_CTRL.ALLNS control the enable state of the SAU and the default security level when the SAU is disabled. Both SAU_CTRL.EN and SAU_CTRL.ALLNS reset to zero disabling the SAU and setting all memory, apart from some specific regions in the PPB space to Secure level. If the SAU is not enabled, and SAU_CTRL.ALLNS is zero, then the IDAU cannot set any regions of memory to a security level lower than Secure, for example Secure NSC or NS. If the SAU is enabled, then SAU_CTRL.ALLNS does not affect the Security level of memory.

RP2350 supports the Armv8-M Protected Memory System Architecture (PMSA). The MPU provides full support for:

• • protection regions
• • access permissions
• • exporting memory attributes to the system

MPU mismatches and permission violations invoke the MemManage handler. For more information, see the Armv8-M Architecture Reference Manual .

You can use the MPU to:

• • enforce privilege rules
• • separate processes
• • manage memory attributes

The MPU supports 16 memory regions: 8 secure and 8 non-secure. The MPU is banked between Secure and Non-secure states. The number of regions in the Secure and Non-secure MPU can be configured independently and each can be programmed to protect memory for the associated Security state.

3.7.4.8. External coprocessors

The external coprocessor interface:

• • Supports low-latency data transfer from the processor to and from the accelerator components.
• • Has a sustained bandwidth up to twice of the processor memory interface.

The following instruction types are supported:

• • Register transfer from the Cortex-M33 processor to the coprocessor MCR , MCRR , MCR2 , MCRR2 .
• • Register transfer from the coprocessor to the Cortex-M33 processor MRC , MRRC , MRC2 , MRRC2 .
• • Data processing instructions CDP , CDP2 .

i NOTE

The regular and extension forms of the coprocessor instructions for example, MCR and MCRR2 , have the same functionality but different encodings. The MRC and MRC2 instructions support the transfer of APSR.NZVC flags when the processor register field is set to PC, for example Rt == 0xF .

3.7.4.8.1. Restrictions

The following restrictions apply when to coprocessor instructions:

• • The LDC(2) or STC(2) instructions are not supported. If these are included in software with the <coproc> field set to a value between 0-7 and the coprocessor is present and enabled in the appropriate fields in the CPACR/NSACR registers, the Cortex-M33 processor always attempts to take an Undefined instruction (UNDEFINSTR) UsageFault exception.
• • The processor register fields for data transfer instructions must not include the stack pointer ( Rt == 0xD ), this encoding is UNPREDICTABLE in the Armv8-M architecture and results in an Undefined instruction (UNDEFINSTR) UsageFault exception in the CPACR/NSACR registers.
• • If any coprocessor instruction is executed when the corresponding coprocessor is disabled in the CPACR/NSACR register, the Cortex-M33 processor always attempts to take a No coprocessor (NOCP) UsageFault exception.

3.7.4.8.2. Data transfer rates

The following table shows the ideal data transfer rates for the coprocessor interface. This means that the coprocessor responds immediately to an instruction. The ideal data transfer rates are sustainable if the corresponding coprocessor instructions are executed consecutively.

The following instructions have the following data transfer rates:

MCR, MCR2 (Processor to coprocessor)

32 bits per cycle

MRC, MRC2 (Coprocessor to processor)

32 bits per cycle

MCRR, MCRR2 (Processor to coprocessor)

64 bits per cycle

MRRC, MRRC2 (Coprocessor to processor)

64 bits per cycle

3.7.4.9. Execution timing

This section describes the execution time of various Cortex-M33 instructions. The results are based on measurements

of a limited and non-exceptional set of examples of the more common instructions and hence may not correctly cover some more unusual situations.

These measurements were taken with the following conditions:

• • only one core is running
• • there are no cache misses (in particular, no XIP cache misses)
• • there there is no active DMA

Any of the above conditions can affect the timing of instruction fetch as well as of load and store operations. See the description of the bus fabric elsewhere in this datasheet for information on possible contention for access to memory.

3.7.4.9.1. Result delays

Some instructions generate results with a two-cycle latency. Using such a result as a source operand for a subsequent instruction incurs a one-cycle result-use penalty . Most of the input values of any instruction count as source operands, including:

• • any source register in a data processing (ALU) instruction
• • any registers used in address generation by an LDR or LDM (including R13 in the case of POP )
• • any registers used in address generation (but not those to be stored) by a STR or STM (including R13 in the case of PUSH ).

The following example shows a load followed by a data-processing instruction, an instruction sequence which incurs this penalty:

LDR R0, [R1]
ADD R1, R0, R2

The following instructions generate results with a two-cycle latency:

• • the destination register arising from some non-simple shifts in certain data-processing instructions (specified in more detail below)
• • the destination register or registers of a multiply instruction
• • the destination register of an LDR
• • the last register in the register list of an LDM or POP unless that register is R15

Using results of the above instructions as a source operand for another instruction incurs a one-cycle penalty between the operations.

3.7.4.9.2. Simple arithmetic and logical instructions

Most data processing instructions execute in a single cycle. Some complex operations (including those listed above and SEL ) incur a result-use penalty.

Complex operations meet at least one of the following criteria:

• • a shifted operand where the shift is not LSL#0 , LSL#1 , LSL#2 or LSL#3
• • an immediate operand which entails a shift (i.e., not of the form 0x000000XY , 0xXYXYXYXY , 0x00XY00XY or 0xXY00XY00 )

When a complex instruction has the -S suffix to set flags, the one-cycle penalty is always incurred, even if the next instruction does not depend on those flag values.

The following operations do not incur a penalty:

AND R0, R1, R2, LSL#4
MOV R3, R4

However, the following operations do incur a penalty:

AND R0, R1, R2, LSL#4
MOV R3, R0

ANDS R0, R1, R2, LSL#4
MOV R3, R4

ADD and SUB are available in variants with a 12-bit plain immediate operand. These do not incur a penalty.

MOV and MOVS with an immediate operand, including MOV with a 16-bit plain immediate operand, do not incur a result-use penalty.

Despite their similarity to logical operations with a shifted operand, UBFX , SBFX and BFI do not incur a result-use penalty.

Simple shift instructions ( LSL , LSR , ASR , and ROR , with the shift amount specified either as an immediate constant or in a register) take one cycle with no result-use penalty.

3.7.4.9.3. Multiply instructions

Multiply and multiply-accumulate instructions execute in a single cycle, but all have a result delay of one cycle.

However, the special case of using the result of a multiply instruction as the accumulate input to a following multiply-accumulate instruction does not incur a one-cycle penalty. As a result, repeated multiply-accumulate operations can run at one per cycle, assuming all of the following conditions hold:

• • the operations accumulate into the same register or register pair
• • the multiplier and multiplicand operands come from other registers

Sequences such as the following can execute one instruction per cycle:

MLA R0, R1, R2, R3
MLA R3, R1, R2, R0
MLA R0, R1, R2, R3
MLA R3, R1, R2, R0
...

UMLAL R0, R1, R4, R5
UMLAL R2, R3, R6, R7
UMLAL R0, R1, R4, R5
UMLAL R2, R3, R6, R7
...

The multiplier requires its multiply operands on cycle n , requires its accumulate operand (if any) on cycle n +1, and makes its result available on cycle n +2.

As a further example, the following sequence completes in 4 cycles:

ADD R2, R0, R1, LSL#23
MLA R3, R4, R5, R2
MOV R6, R3

The ADD would normally incur a one-cycle result-use penalty, but in this case its result is not needed until the second cycle of the multiply-accumulate operation, eliminating the penalty.

3.7.4.9.4. Divide instructions

Let n be the difference between the bit positions of the most significant ones in the absolute value of the dividend and the absolute value of the divisor. If n is negative (in which case the result will be zero), division takes 2 cycles. Otherwise, division takes 4+ n /4 cycles, rounded down.

Using the result of division as input for the next instruction incurs a one-cycle result-use penalty.

3.7.4.9.5. Register loads (LDR and LDM)

Loads execute in one cycle per register, plus a possible one-cycle result delay. Loads can slow down if the addressed memory is not able to accept the read request immediately, for example because of contention with instruction prefetch.

From the point of view of result delays, any register used in address generation counts as a source operand. For examples, see Table 116 .

Table 116. Load instruction source operand examples

There is one cycle of result delay associated with the destination register of an LDR and with the last register in the register list of an LDM or POP . For example, R7 has one cycle of result delay both in LDR R7, [R5, R6] and in LDMIA R0, {R1-R7} . The latter case incurs no result delay associated with R1 to R6 .

Loading R15 does not cause any result delay; however, extra cycles will be taken as described in Section 3.7.4.9.7 .

3.7.4.9.6. Register stores (STR and STM)

Stores, including those which depend on the contents of three different registers such as STR R0, [R1, R2, LSL#2] , execute in one cycle. Like loads, stores can slow down if the addressed memory is not able to accept the request immediately.

The registers involved in address generation, but not the register or registers being stored, count as source operands from the point of view of result delays. For examples, see Table 117 .

Table 117. Register stores source operand examples

3.7.4.9.7. Branches

This section covers any instruction that can change R15 , including the following:

• • MOV R15, Rx

• • BNE
• • BL
• • BX
• • LDR R15, ...
• • POP {..., R15}

When a branch arises from a load (LDR R15, ..., LDMxx Rx, {..., R15}, or POP {..., R15}), the basic time for the instruction is that taken by the load instruction itself, as described in Section 3.7.4.9.5 .

For other instructions that can change R15 (MOV R15, Rx, B<cond>, BL, BX), the basic time for the instruction is zero.

The total time required for a branch that does occur is the basic time + 2 + L + U - (K & F) cycles, and the time required for a branch that does not occur is the basic time + 1 - F cycles, where L, U, F, K are each 0 or 1 as described below:

L

1 when the branch arises from a load (LDR R15, [R6], LDMIA R13, {R0-R3, R15}, and so on); 0 otherwise.

U

1 when the all of following conditions are true:

• • the target address of the branch is not word-aligned
• • the instruction at that address is 32 bits long
• • the instruction executed immediately prior to the branch is not POP or PUSH

If any of the above conditions are not true, U is 0.

F

indicates when the branch can be dual issued (or "folded") with the previous instruction, PrevInst (the instruction executed immediately prior to the branch). F is 1 when all of the following conditions are true:

• • the branch instruction is B, B<cond>, or BX R14 (but not BX to any other register or MOV R15, R14)
• • PrevInst is 16 bits long
• • PrevInst was executed sequentially (i.e., not itself branched to), or PrevInst is word-aligned
• • PrevInst itself was not itself folded with a previous instruction

If any of the above conditions are not true, F is 0.

K

1 when it is known that the branch will execute prior to executing PrevInst; 0 otherwise. In other words, K is 1 unless the branch is conditional and PrevInst sets the flags.

For example, the following delay loop takes 299 cycles:

10000002: MOVs R5, #100
10000004: SUBS R5, R5, #1
10000006: BNE 0x10000004

Those cycles come from the following timings:

• • 1 cycle for MOVs R5, #100
• • 1 cycle for each SUBS R5, R5, #1
• • 2 cycles each for the first 99 BNE instructions (L=U=0, F=1, K=0)
• • 0 cycles for the last, non-taken, BNE (L=U=0, F=1, K=0, using the formula 1-F)

At a different alignment, the same delay loop takes 300 cycles:

10000000: MOVs R5, #100
10000002: SUBS R5, R5, #1
10000004: BNE 0x10000002

Those cycles come from the following timings:

• • 1 cycle for MOV _S R5, #100 ;
• • 1 cycle for each SUB _S R5, R5, #1 ;
• • 2 cycles for the first BNE ( \( L=U=0 \) , \( F=1 \) , \( K=0 \) );
• • 2 cycles each for the next 98 BNE instructions ( \( L=U=0 \) , \( F=K=0 \) );
• • 1 cycle for the last, non-taken, BNE ( \( L=U=0 \) , \( F=K=0 \) , using the formula \( 1-F \) ).

This longer delay loop also takes 300 cycles:

10000000: MOVs R5, #100
10000002: SUBS R5, R5, #1
10000004: MOV R1, R2
10000006: BNE 0x10000002

Those cycles come from the following timings:

• • 1 cycle for MOV _S R5, #100 ;
• • 1 cycle for each SUB _S R5, R5, #1 ;
• • 1 cycle for each MOV R1, R2 ;
• • 1 cycle each for the first 99 BNE instructions ( \( L=U=0 \) , \( F=K=1 \) );
• • 0 cycles for the last, non-taken, BNE ( \( L=U=0 \) , \( F=K=1 \) ; using the formula \( 1-F \) ).

This example illustrates that, if you can contrive to place an instruction between the loop-end test and the branch, it can potentially have zero net cost in execution time.

Another optimisation is to try to ensure that a branch target is either word-aligned or is a 16-bit instruction. Any instruction following a BL can be considered a branch target from this point of view as it is branched to by the return instruction from the subroutine.

If space and cache permit, unrolling loops and inlining subroutines avoids the branch cost altogether.

A sequence of branches not taken will alternately take 0 cycles and 1 cycle. That is the same as a sequence of NOP instructions, which can also be folded. However, this is not the same as sequence of instructions in an IT block that fail their condition.

3.7.4.9.8. IT (if-then) blocks

Instructions within an IT block whose condition fails execute in one cycle.

Most instructions within an IT block whose condition succeeds take the number of cycles they would have taken in their normal, unconditional state.

3.7.4.9.9. Dual issue

When a 16-bit instruction follows a NOP instruction (opcode 0xBF00 , not 0x46C0 ), the instructions are folded , executing the NOP in zero cycles. In some situations, this can help align a branch target to a word-aligned address without an

execution-time penalty.

When a 16-bit opcode follows an IT instruction, the IT instruction executes in zero cycles.

The Cortex-M33 core folds a NOP with the previous instruction ( PrevInst ) if all of the following conditions are true:

• • PrevInst is 16 bits long
• • PrevInst was executed sequentially (not itself branched to) or PrevInst is word-aligned
• • PrevInst was not itself folded with a previous instruction

Branches not taken are in this sense similar to NOP instructions: they can be folded according to the same rule. For further detail on when taken and not taken branches are folded, see Section 3.7.4.9.7 .

When two multi-cycle instructions are folded, at most one cycle can overlap between the instructions.

3.7.4.9.10. Floating-point coprocessor operations

This section describes operations involving the single-precision floating-point coprocessor (FPU). For timings relating to the GPIO coprocessor, the double-precision coprocessor, and the redundancy coprocessor, see Section 3.7.4.9.11 and the detailed descriptions of those coprocessors elsewhere in this document.

Issuing a floating-point instruction occupies the integer core for one cycle. After that, the integer core can proceed with other non-FPU operations without interruption.

Attempting to issue another FPU instruction stalls execution until the FPU is ready to accept the FPU instruction.

The following list details the timings of various FPU instructions:

• • VADD.F32 , VSUB.F32 and VMUL.F32 can execute in one cycle, but have an additional cycle of result delay. As a result, the following example sequence executes at two cycles per instruction:

VADD.F32 s0, s0, s2
VADD.F32 s0, s0, s3
VADD.F32 s0, s0, s4
VADD.F32 s0, s0, s5
...

The following interleaved example, however, executes at one cycle per instruction:

VADD.F32 s0, s0, s2
VADD.F32 s1, s1, s3
VADD.F32 s0, s0, s4
VADD.F32 s1, s1, s5
...

Furthermore, you can interleave VADD.F32 , VSUB.F32 and VMUL.F32 instructions arbitrarily to execute in one cycle, as long as no instruction depends on the result of its predecessor.

• • VMLA.F32 and VFMA.F32 occupy the FPU for 3 cycles, plus one cycle of result delay.

However, consecutive VMLA.F32 or VFMA.F32 instructions accumulating into the same register can run at one instruction every three cycles.

• • When the work can be interleaved, separate VMUL.F32 and VADD.F32 instructions are faster than a single VMLA.F32 instruction.
• • VDIV.F32 and VSQRT.F32 occupy the FPU for 14 cycles, plus one cycle of result delay.
• • VMOV.F32 Sx, Ry (move one word from integer register to coprocessor) takes one cycle.

• • VMOV.F32 Rx,Sy (move one word from coprocessor to integer register) takes one cycle plus one cycle of result delay.
• • VMOV.F32 Sx,Sy (move one word between coprocessor registers) takes one cycle.
• • VMOV.F64 Dx,Ry,Rz (move two words from integer registers to coprocessor) occupies the FPU for two cycles and the integer core for one cycle.
• • VMOV.F64 Rx,Ry,Dz (move two words from coprocessor to integer registers) occupies both the FPU and the integer core for two cycles.

3.7.4.9.11. Other coprocessor operations

A coprocessor can stall an operation if it is not ready. For more information, see the documentation for the specific coprocessor.

The following list details the timings of various coprocessor instructions:

• • Assuming that no stalls occur, a CDP instruction takes one cycle.
• • An MCR instruction (move one word from integer register to coprocessor) takes one cycle.
• • An MRC instruction (move one word from coprocessor to integer register) takes one cycle, plus one cycle of result delay.
• • An MCRR instruction (move two words from integer registers to coprocessor) takes one cycle.
• • An MRRC instruction (move two words from coprocessor to integer registers) takes one cycle, plus one cycle of result delay.

3.7.4.9.12. Instruction fetch

Each Cortex-M33 core has separate instruction and data buses ("Harvard architecture"). Each core has a bandwidth to memory of 32 bits per cycle. Since each instruction is at most 32 bits long, for sequential code the instruction prefetcher has enough bandwidth to ensure that the processor core always has instructions.

In RP2350, contention can occur when the instruction and data buses attempt to access data stored in memory connected to the same downstream port of the AHB5 crossbar. For example, code running from the main SRAM might attempt to load a literal stored nearby. That load might conflict with an instruction prefetch to the same SRAM. To reduce the chance of this conflict, the main SRAM is striped into banks across groups of four words: words at addresses that are different modulo 16 are stored in different banks.

Since the prefetcher typically runs about two words (8 bytes) ahead of execution, that means that an instruction that reads 8 (modulo 16) bytes ahead of itself is liable to result in a conflict. For example, the following instruction, which reads 40 bytes ahead (because here PC means the address of the next instruction), can sometimes incur a penalty of one cycle:

LDR R8,[PC,#32] @ 32-bit instruction

3.7.4.10. Debug

Cortex-M33 debug functionality includes processor halt, single-step, processor core register access, Vector Catch, unlimited software breakpoints, and full system memory access.

The processor also includes support for hardware breakpoints and watchpoints configured during implementation:

• • A breakpoint unit supporting eight instruction comparators
• • A watchpoint unit supporting four data watchpoint comparators

The Cortex-M33 processor supports system level debug authentication to control access from a debugger to resources

and memory. Authentication via the Armv8-M Security Extension can be used to allow a debugger full access to Non-secure code and data without exposing any Secure information.

The processor implementation can be partitioned to place the debug components in a separate power domain from the processor core and NVIC.

All debug registers are accessible by the D-AHB interface.

For more information, see the Armv8-M Architecture Reference Manual .

3.7.4.11. Data Watchpoint and Trace unit (DWT)

The DWT is a full configuration, containing four comparators ( DWT_COMP0 to DWT_COMP3 ). These comparators support the following features:

• • Hardware watchpoint support
• • Hardware trace packet support
• • CMPMATCH support for ETM/MTB/CTI triggers
• • Cycle counter matching support ( DWT_COMP0 only)
• • Instruction address matching support
• • Data address matching support
• • Data value matching support ( DWT_COMP1 only in a reduced DWT, DWT_COMP3 only in a Full DWT)
• • Linked/limit matching support ( DWT_COMP1 and DWT_COMP3 only)

The DWT contains counters for:

• • Cycles ( DWT_CYCCNT.CYCCNT )
• • Folded Instructions (FOLDCNT)
• • Additional cycles required to execute all load/store instructions (LSUCNT)
• • Processor sleep cycles (SLEEPCNT)
• • Additional cycles required to execute multi-cycle instructions and instruction fetch stalls (CPICNT)
• • Cycles spent in exception processing (EXCCNT)

Before using DWT, set the DEMCR.TRCENA bit to 1.

The DWT provides periodic requests for protocol synchronization to the ITM and the TPIU.

3.7.4.12. Cross Trigger Interface (CTI)

The CTI enables the debug logic, MTB, and ETM to interact with each other and with other CoreSight components. This is called cross triggering. For example, you can configure the CTI to generate an interrupt when the ETM trigger event occurs or to start tracing when a DWT comparator match is detected.

The following figure shows the debug system components and the available trigger inputs and trigger outputs:

Figure 15 shows the components of the debug system.

Figure 15. Debug system components

graph LR
    subgraph Processor
        direction TB
        P1[Extern debug request] --> CTI
        P2[Debug request] --> CTI
        P3[Extern restart request] --> CTI
        P4[Restart request] --> CTI
        P5[Interrupt requests] --> CTI
        P6[Processor halted] --> CTI
        P7[DWT comparator outputs] --> CTI
    end
    subgraph ETM
        direction TB
        E1[ETM event outputs] --> CTI
        E2[ETM event inputs] --> CTI
    end
    subgraph MTB
        direction TB
        M1[MTB Trace start] --> CTI
        M2[MTB Trace stop] --> CTI
    end
    subgraph CTI
        direction TB
        C1[CTI input channels]
        C2[CTI output channels]
    end

The following table shows how the CTI trigger inputs are connected to the Cortex-M33 processor:

Table 118. Trigger signals to the CTI

The following table shows how the CTI trigger outputs are connected to the processor and ETM:

Table 119. Trigger signals from the CTI

After the processor is halted using CTI Trigger Output 0, the Processor Debug Request signal remains asserted. The debugger must write to CTIINTACK to clear the halting request before restarting the processor.

After asserting an interrupt using the CTI Trigger Output 1 or 2, the Interrupt Service Routine (ISR) must clear the interrupt request by writing to the CTI Interrupt Acknowledge, CTIINTACK .

Interrupt requests from the CTI to the system are only asserted when invasive debug is enabled in the processor.

3.7.4.12.1. CTI programmers model

The following table shows the CTI programmable registers, with address offset, type, and reset value for each register. See the Arm CoreSight™ SoC-400 Technical Reference Manual for register descriptions.

Table 120. Cortex-M33
CTI register summary

3.7.5. List of registers

The Arm Cortex-M33 registers start at a base address of 0xe0000000, defined as PPB_BASE in the SDK.

Table 121. List of M33 registers