RP2040 Datasheet

A microcontroller by Raspberry Pi

Colophon

© 2020-2025 Raspberry Pi Ltd (formerly Raspberry Pi (Trading) Ltd.)

This documentation is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International (CC BY-ND).

Portions Copyright © 2019 Synopsys, Inc.

All rights reserved. Used with permission. Synopsys & DesignWare are registered trademarks of Synopsys, Inc.

Portions Copyright © 2000-2001, 2005, 2007, 2009, 2011-2012, 2016 Arm Limited.

All rights reserved. Used with permission.

build-date: 2025-02-20

build-version: 3184e62-clean

Legal disclaimer notice

TECHNICAL AND RELIABILITY DATA FOR RASPBERRY PI PRODUCTS (INCLUDING DATASHEETS) AS MODIFIED FROM TIME TO TIME ("RESOURCES") ARE PROVIDED BY RASPBERRY PI LTD ("RPL") "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW IN NO EVENT SHALL RPL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THE RESOURCES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

RPL reserves the right to make any enhancements, improvements, corrections or any other modifications to the RESOURCES or any products described in them at any time and without further notice.

The RESOURCES are intended for skilled users with suitable levels of design knowledge. Users are solely responsible for their selection and use of the RESOURCES and any application of the products described in them. User agrees to indemnify and hold RPL harmless against all liabilities, costs, damages or other losses arising out of their use of the RESOURCES.

RPL grants users permission to use the RESOURCES solely in conjunction with the Raspberry Pi products. All other use of the RESOURCES is prohibited. No licence is granted to any other RPL or other third party intellectual property right.

HIGH RISK ACTIVITIES. Raspberry Pi products are not designed, manufactured or intended for use in hazardous environments requiring fail safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, weapons systems or safety-critical applications (including life support systems and other medical devices), in which the failure of the products could lead directly to death, personal injury or severe physical or environmental damage ("High Risk Activities"). RPL specifically disclaims any express or implied warranty of fitness for High Risk Activities and accepts no liability for use or inclusions of Raspberry Pi products in High Risk Activities.

Raspberry Pi products are provided subject to RPL’s Standard Terms. RPL’s provision of the RESOURCES does not expand or otherwise modify RPL’s Standard Terms including but not limited to the disclaimers and warranties expressed in them.

Table of contents

Colophon .

Legal disclaimer notice

1. Introduction. 8

1.1. Why is the chip called RP2040?. 8
1.2. Summary 9
1.3. The Chip . 9
1.4. Pinout Reference. 10

1.4.1. Pin Locations . 10
1.4.2. Pin Descriptions . 11
1.4.3. GPIO Functions 12

2. System Description 14

2.1. Bus Fabric 14

2.1.1. AHB-Lite Crossbar . 15
2.1.2. Atomic Register Access 17
2.1.3. APB Bridge . 17
2.1.4. Narrow IO Register Writes. 17
2.1.5. List of Registers . 18

2.2. Address Map . 24

2.2.1. Summary. . . 24
2.2.2. Detail . 24

2.3. Processor subsystem. . 26

2.3.1. SIO . . 27
2.3.2. Interrupts. . 60
2.3.3. Event Signals 61
2.3.4. Debug 61

2.4. Cortex-M0+ 62

2.4.1. Features 62
2.4.2. Functional Description 64
2.4.3. Programmer’s model. 68
2.4.4. System control . 73
2.4.5. NVIC. 74
2.4.6. MPU. . 76
2.4.7. Debug 76
2.4.8. List of Registers . . 77

2.5. DMA . 91

2.5.1. Configuring Channels . 91
2.5.2. Starting Channels. 93
2.5.3. Data Request (DREQ). 95
2.5.4. Interrupts. 96
2.5.5. Additional Features . 96
2.5.6. Example Use Cases . 97
2.5.7. List of Registers . . 101

2.6. Memory . 120

2.6.1. ROM. . 120
2.6.2. SRAM . 121
2.6.3. Flash . 122

2.7. Boot Sequence . 128

2.8. Bootrom . . 128

2.8.1. Processor Controlled Boot Sequence . . 129
2.8.2. Launching Code On Processor Core 1 . 131
2.8.3. Bootrom Contents . . 132
2.8.4. USB Mass Storage Interface . 143
2.8.5. USB PICOBOOT Interface . 144

2.9. Power Supplies . . 150

2.9.1. Digital IO Supply (IOVDD) . 151

2.9.2. Digital Core Supply (DVDD). . 151
2.9.3. On-Chip Voltage Regulator Input Supply (VREG_VIN) . . 151
2.9.4. USB PHY Supply (USB_VDD) . 151
2.9.5. ADC Supply (ADC_AVDD) . . 152
2.9.6. Power Supply Sequencing . 152
2.9.7. Power Supply Schemes . 152

2.10. Core Supply Regulator . 155

2.10.1. Application Circuit . . . 155
2.10.2. Operating Modes . . . 156
2.10.3. Output Voltage Select . . 157
2.10.4. Status . . 157
2.10.5. Current Limit . 157
2.10.6. List of Registers. . 157
2.10.7. Detailed Specifications . . . 160

2.11. Power Control . . 160

2.11.1. Top-level Clock Gates . . 160
2.11.2. SLEEP State . 161
2.11.3. DORMANT State 161
2.11.4. Memory Power Down . . 161
2.11.5. Programmer’s Model . 162

2.12. Chip-Level Reset . . 163

2.12.1. Overview . 163
2.12.2. Power-on Reset . 164
2.12.3. Brown-out Detection . . 165
2.12.4. Supply Monitor. . . 167
2.12.5. External Reset . 167
2.12.6. Rescue Debug Port Reset. . 167
2.12.7. Source of Last Reset. . 168
2.12.8. List of Registers. . 168

2.13. Power-On State Machine . . 168

2.13.1. Overview . . 168
2.13.2. Power On Sequence . 168
2.13.3. Register Control . . 169
2.13.4. Interaction with Watchdog . . 169
2.13.5. List of Registers. . 169

2.14. Subsystem Resets . 172

2.14.1. Overview . . 172
2.14.2. Programmer’s Model . 173
2.14.3. List of Registers. 175

2.15. Clocks . 178

2.15.1. Overview . 178
2.15.2. Clock sources . 179
2.15.3. Clock Generators. 183
2.15.4. Frequency Counter . 186
2.15.5. Resus . 187
2.15.6. Programmer’s Model . 187
2.15.7. List of Registers. . 194

2.16. Crystal Oscillator (XOSC). . 216

2.16.1. Overview . . 216
2.16.2. Usage . . 217
2.16.3. Startup Delay . . 217
2.16.4. XOSC Counter . 217
2.16.5. DORMANT mode . . 218
2.16.6. Programmer’s Model . 218
2.16.7. List of Registers. . 219

2.17. Ring Oscillator (ROSC) . . 221

2.17.1. Overview . . 221
2.17.2. ROSC/XOSC trade-offs . . . 222
2.17.3. Modifying the frequency. . 222
2.17.4. ROSC divider . 223

2.17.5. Random Number Generator . 223
2.17.6. ROSC Counter 223
2.17.7. DORMANT mode . . 223
2.17.8. List of Registers. 224

2.18. PLL . 228

2.18.1. Overview . . 228
2.18.2. Calculating PLL parameters. 228
2.18.3. Configuration 232
2.18.4. List of Registers. 234

2.19. GPIO . . 236

2.19.1. Overview . . 236
2.19.2. Function Select 237
2.19.3. Interrupts 239
2.19.4. Pads . 240
2.19.5. Software Examples . . 241
2.19.6. List of Registers. 244

2.20. Sysinfo . . 305

2.20.1. Overview . 305
2.20.2. List of Registers. . 305

2.21. Syscfg . 306

2.21.1. Overview . . 306
2.21.2. List of Registers. . 306

2.22. TBMAN. . 309

2.22.1. List of Registers. 309

3. PIO . 311

3.1. Overview . 311

3.2. Programmer’s Model . 312

3.2.1. PIO Programs. . 312
3.2.2. Control Flow . . 313
3.2.3. Registers. . 314
3.2.4. Stalling . 317
3.2.5. Pin Mapping . . 318
3.2.6. IRQ Flags. . 318
3.2.7. Interactions Between State Machines . 318

3.3. PIO Assembler (pioasm) . 319

3.3.1. Directives . 319
3.3.2. Values . . 320
3.3.3. Expressions . 320
3.3.4. Comments . 320
3.3.5. Labels . 320
3.3.6. Instructions. . 321
3.3.7. Pseudoinstructions . 321

3.4. Instruction Set . . 321

3.4.1. Summary. . . 321
3.4.2. JMP . . 322
3.4.3. WAIT . 323
3.4.4. IN . . 324
3.4.5. OUT 325
3.4.6. PUSH . . 326
3.4.7. PULL . 327
3.4.8. MOV. . 328
3.4.9. IRQ . . 329
3.4.10. SET . 330

3.5. Functional Details . 331

3.5.1. Side-set . . 331
3.5.2. Program Wrapping 332
3.5.3. FIFO Joining . . 334
3.5.4. Autopush and Autopull . . 335
3.5.5. Clock Dividers . 339
3.5.6. GPIO Mapping . 340

3.5.7. Forced and EXEC’d Instructions. . 342

3.6. Examples . . 344

3.6.1. Duplex SPI . 344
3.6.2. WS2812 LEDs. 348
3.6.3. UART TX . . 350
3.6.4. UART RX . . 352
3.6.5. Manchester Serial TX and RX. . 355
3.6.6. Differential Manchester (BMC) TX and RX . 357
3.6.7. I2C . . 361
3.6.8. PWM . 364
3.6.9. Addition. 366
3.6.10. Further Examples. . 367

3.7. List of Registers . 368

4. Peripherals . 383

4.1. USB. . 383

4.1.1. Overview . . 383
4.1.2. Architecture 384
4.1.3. Programmer’s Model. . 394
4.1.4. List of Registers . . 398

References . 417

4.2. UART . 417

4.2.1. Overview . . 417
4.2.2. Functional description. . . 418
4.2.3. Operation . 420
4.2.4. UART hardware flow control . 422
4.2.5. UART DMA Interface . . 424
4.2.6. Interrupts . 425
4.2.7. Programmer’s Model. . . 427
4.2.8. List of Registers . . 429

4.3. I2C. . 440

4.3.1. Features . 440
4.3.2. IP Configuration . . 441
4.3.3. I2C Overview. . . 441
4.3.4. I2C Terminology. . 443
4.3.5. I2C Behaviour . . 444
4.3.6. I2C Protocols . . 445
4.3.7. Tx FIFO Management and START, STOP and RESTART Generation. . 448
4.3.8. Multiple Master Arbitration. . 450
4.3.9. Clock Synchronization. . . 451
4.3.10. Operation Modes . . 452
4.3.11. Spike Suppression. . 457
4.3.12. Fast Mode Plus Operation . 458
4.3.13. Bus Clear Feature . 458
4.3.14. IC_CLK Frequency Configuration . . 459
4.3.15. DMA Controller Interface . 463
4.3.16. Operation of Interrupt Registers . 464
4.3.17. List of Registers. . 464

4.4. SPI . 501

4.4.1. Overview . . 502
4.4.2. Functional Description . 502
4.4.3. Operation . 505
4.4.4. List of Registers . . 515

4.5. PWM. . 521

4.5.1. Overview . . 521
4.5.2. Programmer’s Model. . 522
4.5.3. List of Registers . . 529

4.6. Timer . 534

4.6.1. Overview . . 534
4.6.2. Counter . . 535
4.6.3. Alarms. . 535

4.6.4. Programmer’s Model. . 536
4.6.5. List of Registers . 539

4.7. Watchdog. . 544

4.7.1. Overview . . 544
4.7.2. Tick generation . 544
4.7.3. Watchdog Counter. . 545
4.7.4. Scratch Registers. . 545
4.7.5. Programmer’s Model. . 545
4.7.6. List of Registers . . 547

4.8. RTC. . 548

4.8.1. Storage Format . 548
4.8.2. Leap year . 549
4.8.3. Interrupts . 549
4.8.4. Reference clock . . 549
4.8.5. Programmer’s Model. . 550
4.8.6. List of Registers . . 553

4.9. ADC and Temperature Sensor. . 557

4.9.1. ADC controller . 558
4.9.2. SAR ADC . . 559
4.9.3. ADC ENOB . 561
4.9.4. INL and DNL . 562
4.9.5. Temperature Sensor . . 563
4.9.6. List of Registers . . 564

4.10. SSI . 567

4.10.1. Overview . . 568
4.10.2. Features . 568
4.10.3. IP Modifications. . 569
4.10.4. Clock Ratios . . 570
4.10.5. Transmit and Receive FIFO Buffers. . 571
4.10.6. 32-Bit Frame Size Support . 572
4.10.7. SSI Interrupts . 572
4.10.8. Transfer Modes . 573
4.10.9. Operation Modes . . 574
4.10.10. Partner Connection Interfaces. . 579
4.10.11. DMA Controller Interface . 595
4.10.12. APB Interface. . 597
4.10.13. List of Registers. . 598

5. Electrical and Mechanical. 607

5.1. Package . . 607

5.1.1. Thermal characteristics . 608
5.1.2. Recommended PCB Footprint 608
5.1.3. Package markings. 608

5.2. Storage conditions . 609

5.3. Solder profile . . . 609

5.4. Compliance . . 611

5.5. Pinout . . 611

5.5.1. Pin Locations . . 611
5.5.2. Pin Definitions . 612
5.5.3. Pin Specifications . 614

5.6. Power Supplies . . 622

5.7. Power Consumption. . 622

5.7.1. Peripheral power consumption . 622
5.7.2. Power consumption for typical user cases . 623

Appendix A: Register Field Types. 625

Standard types . . 625

RW: . . 625
RO: . 625
WO:. . 625

Clear types . 625

SC. . 625

WC . 625

FIFO types . 626

RWF 626

RF . 626

WF . 626

Appendix B: Errata . . 627

Bootrom. 627

RP2040-E9. 627

RP2040-E14 . 627

Clocks . 628

RP2040-E7. 628

RP2040-E10 628

DMA . 629

RP2040-E12 . 629

RP2040-E13 629

GPIO / ADC . . 630

RP2040-E6. 630

RP2040-E11 . 630

USB . 630

RP2040-E2. 630

RP2040-E3. . 631

RP2040-E4. 631

RP2040-E5. . 631

RP2040-E15 . 633

RP2040-E16 . 634

Watchdog . 634

RP2040-E1. . 634

XIP Flash . . 635

RP2040-E8. 635

Appendix C: Availability . . 636

Support . 636

Ordering code . . 636

Documentation Release History. . 637

20 February 2025 . 637

15 October 2024. . 637

02 May 2024 . . 637

02 February 2024 . . 637

14 June 2023 . 637

03 March 2023 . 637

01 December 2022. . 637

30 June 2022 . 638

17 June 2022 . 638

04 November 2021. . 638

03 November 2021. . 638

30 September 2021 . 638

23 June 2021 . 638

07 June 2021 . 639

13 April 2021. . 639

07 April 2021. . 639

05 March 2021 . 639

23 February 2021 . 639

01 February 2021 . 639

26 January 2021. . 639

21 January 2021. . 640

Chapter 1. Introduction

Microcontrollers connect the world of software to the world of hardware. They allow developers to write software which interacts with the physical world in the same deterministic, cycle-accurate manner as digital logic. They occupy the bottom left corner of the price/performance space, outselling their more powerful brethren by a factor of ten to one. They are the workhorses that power the digital transformation of our world.

RP2040 is the debut microcontroller from Raspberry Pi. It brings our signature values of high performance, low cost, and ease of use to the microcontroller space.

With a large on-chip memory, symmetric dual-core processor complex, deterministic bus fabric, and rich peripheral set augmented with our unique Programmable I/O (PIO) subsystem, it provides professional users with unrivalled power and flexibility. With detailed documentation, a polished MicroPython port, and a UF2 bootloader in ROM, it has the lowest possible barrier to entry for beginner and hobbyist users.

RP2040 is a stateless device, with support for cached execute-in-place from external QSPI memory. This design decision allows you to choose the appropriate density of non-volatile storage for your application, and to benefit from the low pricing of commodity Flash parts.

RP2040 is manufactured on a modern 40nm process node, delivering high performance, low dynamic power consumption, and low leakage, with a variety of low-power modes to support extended-duration operation on battery power.

Key features:

• Dual ARM Cortex-M0+ @ 133MHz
• 264kB on-chip SRAM in six independent banks
• Support for up to 16MB of off-chip Flash memory via dedicated QSPI bus
• DMA controller
• Fully-connected AHB crossbar
• Interpolator and integer divider peripherals
• On-chip programmable LDO to generate core voltage
• 2 on-chip PLLs to generate USB and core clocks
• 30 GPIO pins, 4 of which can be used as analogue inputs
• Peripherals

◦ 2 UARTs
◦ 2 SPI controllers
◦ 2 I2C controllers
◦ 16 PWM channels
◦ USB 1.1 controller and PHY, with host and device support
◦ 8 PIO state machines

Whatever your microcontroller application, from machine learning to motor control, from agriculture to audio, RP2040 has the performance, feature set, and support to make your product fly.

1.1. Why is the chip called RP2040?

The post-fix numeral on RP2040 comes from the following,

1. Number of processor cores (2)
2. Loosely which type of processor (M0+)
3. floor(log2(RAM / 16kB))
4. floor(log2(nonvolatile / 128kB)) or 0 if no onboard nonvolatile storage

see Figure 1.
Figure 1. An explanation for the name of the RP2040 chip.

1.2. Summary

RP2040 is a low-cost, high-performance microcontroller device with flexible digital interfaces. Key features:

• Dual Cortex M0+ processor cores, up to 133MHz (or 200MHz at 1.15V, see Section 2.15.3)
• 264kB of embedded SRAM in 6 banks
• 30 multifunction GPIO
• 6 dedicated IO for SPI Flash (supporting XIP)
• Dedicated hardware for commonly used peripherals
• Programmable IO for extended peripheral support
• 4 channel ADC with internal temperature sensor, 500ksps, 12-bit conversion
• USB 1.1 Host/Device

1.3. The Chip

RP2040 has a dual M0+ processor cores, DMA, internal memory and peripheral blocks connected via AHB/APB bus fabric.

Figure 2. A system overview of the RP2040 chip

graph TD
    subgraph RP2040
        direction LR
        A["IOs"] --> B["Crystal"]
        B --> C["Clock generation"]
        C --> D["Internal oscillator"]
        D --> E["PLL"]
        D --> F["PLL"]
        G["SWD"] --> H["GPIO [29:0"]]
        H --> I["QSPI"]
        I --> J["Core Supply Regulator"]
    end

    subgraph CPU
        K["Peripherals"] --> L["SPI x2"]
        K --> M["PWM"]
        K --> N["UART x2"]
        K --> O["Timer"]
        K --> P["RTC"]
        K --> Q["I2C x2"]
        K --> R["ADC & TS"]
        S["Reset control"] --> T["Power on state machine"]
        U["Power on state machine"] --> V["Sysctrl"]
        W["Sysctrl"] --> X["Sysinfo"]
        Y["Sysinfo"] --> Z["Watchdog"]
    end

    subgraph Memory
        AA["Bus Fabric"] --> AB["PIO0"]
        AA --> AC["PIO1"]
        AB --> AD["XIP / Cache"]
        AC --> AE["ROM"]
        AC --> AF["SRAM"]
        AC --> AG["SRAM"]
        AC --> AH["SRAM"]
        AC --> AI["SRAM"]
        AC --> AJ["SRAM"]
        AC --> AK["SRAM"]
        AC --> AL["SRAM"]
        AC --> AM["SRAM"]
        AC --> AN["SRAM"]
        AC --> AO["SRAM"]
        AC --> AP["SRAM"]
        AC --> AQ["SRAM"]
        AC --> AR["SRAM"]
        AC --> AS["SRAM"]
        AC --> AT["SRAM"]
        AC --> AU["SRAM"]
        AC --> AV["SRAM"]
        AC --> AW["SRAM"]
        AC --> AX["SRAM"]
        AC --> AY["SRAM"]
        AC --> AZ["SRAM"]
        AC --> BA["SRAM"]
        AC --> BB["SRAM"]
        AC --> BC["SRAM"]
        AC --> BD["SRAM"]
        AC --> BE["SRAM"]
        AC --> BF["SRAM"]
        AC --> BG["SRAM"]
        AC --> BH["SRAM"]
        AC --> BI["SRAM"]
        AC --> BJ["SRAM"]
        AC --> BK["SRAM"]
        AC --> BL["SRAM"]
        AC --> BM["SRAM"]
        AC --> BN["SRAM"]
        AC --> BO["SRAM"]
        AC --> BP["SRAM"]
        AC --> BQ["SRAM"]
        AC --> BR["SRAM"]
        AC --> BS["SRAM"]
        AC --> BT["SRAM"]
        AC --> BU["SRAM"]
        AC --> BV["SRAM"]
        AC --> BW["SRAM"]
        AC --> BX["SRAM"]
        AC --> BYB["SRAM"]
        AC --> BZ["SRAM"]
        AC --> CA["SRAM"]
        AC --> CB["SRAM"]
        AC --> CC["SRAM"]
        AC --> CD["SRAM"]
        AC --> CE["SRAM"]
        AC --> CF["SRAM"]
        AC --> CG["SRAM"]
        AC --> CH["SRAM"]
        AC --> CI["SRAM"]
        AC --> CJ["SRAM"]
        AC --> CK["SRAM"]
    end

    subgraph Control
        L
        M
        N
    end

    subgraph Data
        D
    end

    subgraph Data
    E
    end

    subgraph Data
    K
    end

    subgraph Data
    L
    end

    subgraph Data
    M
    end

    subgraph Data
    N
    end

    subgraph Data
    O
    end

    subgraph Data
    P
    end

    subgraph Data
    Q
    end

    subgraph Data
    R
    end

    subgraph Data
    S
    end

    subgraph Data
    T
    end

    subgraph Data
    U
    end

    subgraph Data
    V
    end

    subgraph Data
    W
    end

    subgraph Data
    X
    end

    subgraph Data
    Y
    end

    subgraph Data
    Z
    end

    subgraph Data
    AA
    end

    subgraph Data
    AB
    end

    subgraph Data
    AC
    end

    subgraph Data
    AD
    end

    subgraph Data
    AE
    end

    subgraph Data
    AF
    end

    subgraph Data
    AG
    end

    subgraph Data
    AH
    end

    subgraph Data
    AI
    end

    subgraph Data
    AJ
    end

    subgraph Data
    AK
    end

    subgraph Data
    AL
    end

    subgraph Data
    AM
    end

    subgraph Data
    AN
    end

    subgraph Data
    AO
    end

    subgraph Data
    AP
    end

    subgraph Data
    AQ
    end

    subgraph Data
    AR
    end

    subgraph Data
    AS
    end

    subgraph Data
    AT
    end

    subgraph Data
    AU
    end

    subgraph Data
    AV
    end

    subgraph Data
    AW
    end

    subgraph Data
    AX
    end

    subgraph Data
    AY
    end

    subgraph Data
    AZ
    end

    subgraph Data
    BA
    end

    subgraph Data
    BB
    end

    subgraph Data
    BC
    end

    subgraph Data
    BD
    end

Code may be executed directly from external memory through a dedicated SPI, DSPI or QSPI interface. A small cache improves performance for typical applications.

Debug is available via the SWD interface.

Internal SRAM can contain code or data. It is addressed as a single 264 kB region, but physically partitioned into 6 banks to allow simultaneous parallel access from different masters.

DMA bus masters are available to offload repetitive data transfer tasks from the processors.

GPIO pins can be driven directly, or from a variety of dedicated logic functions.

Dedicated hardware for fixed functions such as SPI, I2C, UART.

Flexible configurable PIO controllers can be used to provide a wide variety of IO functions.

A USB controller with embedded PHY can be used to provide FS/LS Host or Device connectivity under software control.

Four ADC inputs which are shared with GPIO pins.

Two PLLs to provide a fixed 48MHz clock for USB or ADC, and a flexible system clock up to 133MHz.

An internal Voltage Regulator to supply the core voltage so the end product only needs supply the IO voltage.

1.4. Pinout Reference

This section provides a quick reference for pinout and pin functions. Full details, including electrical specifications and package drawings, can be found in Chapter 5.

1.4.1. Pin Locations

Figure 3. RP2040
Pinout for QFN-56
7×7mm (reduced ePad size)

1.4.2. Pin Descriptions

Table 1. The function of each pin is briefly described here. Full electrical specifications can be found in Chapter 5.

1.4.3. GPIO Functions

Each individual GPIO pin can be connected to an internal peripheral via the GPIO functions defined below. Some internal peripheral connections appear in multiple places to allow some system level flexibility. SIO, PIO0 and PIO1 can connect to all GPIO pins and are controlled by software (or software controlled state machines) so can be used to implement many functions.

Table 2. General Purpose Input/Output (GPIO) Bank 0 Functions

Table 3. GPIO bank 0 function descriptions

Chapter 2. System Description

This chapter describes the RP2040 key system features including processor, memory, how blocks are connected, clocks, resets, power, and IO. Refer to Figure 2 for an overview diagram.

2.1. Bus Fabric

The RP2040 bus fabric routes addresses and data across the chip.

Figure 4 shows the high-level structure of the bus fabric. The main AHB-Lite crossbar routes addresses and data between its 4 upstream ports and 10 downstream ports: up to four bus transfers can take place each cycle. All data paths are 32 bits wide. Memory devices have dedicated ports on the main crossbar, to satisfy their high bandwidth requirements. High-bandwidth AHB-Lite peripherals have a shared port on the crossbar, and an APB bridge provides bus access to system control registers and lower-bandwidth peripherals.

Figure 4. RP2040 bus fabric overview.

graph TD
    A["Cortex-M0+ Core 0"] --> B["AHB-Lite Crossbar 4:10"]
    C["Cortex-M0+ Core 1"] --> B
    D["System DMA 1-Write 1-Read"] --> B
    B --> E["ROM 16 kB"]
    B --> F["SRAM0 64 kB"]
    B --> G["SRAM1 64 kB"]
    B --> H["SRAM2 64 kB"]
    B --> I["SRAM3 64 kB"]
    B --> J["SRAM4 4 kB"]
    B --> K["SRAM5 4 kB"]
    B --> L["APB Bridge"]
    M["Control"] --> B
    N["AHB-Lite Splitter"] --> O["Flash XIP"]
    N --> P["PIO0"]
    N --> Q["PIO1"]
    N --> R["USB"]
    S["APB Splitter"] --> T["UART0"]
    S --> U["UART1"]
    S --> V["SPIO"]
    S --> W["SPI0"]
    S --> X["SPI1"]
    S --> Y["I2C0"]
    S --> Z["I2C1"]
    S --> AA["ADC"]
    S --> AB["PWM"]
    S --> AC["Timer"]
    S --> AD["Watch-dog"]
    S --> AE["RTC"]
    S --> AF["Other peripherals and system control registers"]

The bus fabric connects 4 AHB-Lite masters, i.e. devices which generate addresses:

• Processor core 0
• Processor core 1
• DMA controller Read port
• DMA controller Write port

These are routed through to 10 downstream ports on the main crossbar:

• ROM
• Flash XIP
• SRAM 0 to 5 (one port each)
• Fast AHB-Lite peripherals: PIO0, PIO1, USB, DMA control registers, XIP aux (one shared port)
• Bridge to all APB peripherals, and system control registers

The four bus masters can access any four different crossbar ports simultaneously, the bus fabric does not add wait states to any AHB-Lite slave access. So at a system clock of 125MHz the maximum sustained bus bandwidth is 2.0GBps. The system address map has been arranged to make this parallel bandwidth available to as many software use cases as possible — for example, the striped SRAM alias (Section 2.6.2) scatters main memory accesses across four crossbar ports (SRAM0…3), so that more memory accesses can proceed in parallel.

2.1.1. AHB-Lite Crossbar

At the centre of the RP2040 bus fabric is a 4:10 fully-connected crossbar. Its 4 upstream ports are connected to the 4 system bus masters, and the 10 downstream ports connect to the highest-bandwidth AHB-Lite slaves (namely the memory interfaces) and to lower layers of the fabric. Figure 5 shows the structure of a 2:3 AHB-Lite crossbar, arranged identically to the 4:10 crossbar on RP2040, but easier to show in the diagram.

Figure 5. A 2:3 AHB-Lite crossbar. Each upstream port connects to a splitter, which routes bus requests toward one of the 3 downstream ports, and routes responses back. Each downstream port connects to an arbiter, which safely manages concurrent access to the port.

graph TD
    A["Splitter 1:3"] --> B["Arbiter 2:1"]
    A --> C["Arbiter 2:1"]
    A --> D["Arbiter 2:1"]
    E["Splitter 1:3"] --> F["Arbiter 2:1"]
    E --> G["Arbiter 2:1"]
    E --> H["Arbiter 2:1"]
    I["Upstream Port 0"] --> A
    J["Upstream Port 1"] --> E
    K["Downstream Port 0"] --> B
    L["Downstream Port 1"] --> C
    M["Downstream Port 2"] --> D

The crossbar is built from two components:

• Splitters

◦ Perform coarse address decode
◦ Route requests (addresses, write data) to the downstream port indicated by the initial address decode
◦ Route responses (read data, bus errors) from the correct arbiter back to the upstream port

• Arbiters

◦ Manage concurrent requests to a downstream port
◦ Route responses (read data, bus errors) to the correct splitter
◦ Implement bus priority rules

The main crossbar on RP2040 consists of 4 1:10 splitters and 10 4:1 arbiters, with a mesh of 40 AHB-Lite bus channels between them. Note that, as AHB-Lite is a pipelined bus, the splitter may be routing back a response to an earlier request from downstream port A, whilst a new request to downstream port B is already in progress. This does not incur any cycle penalty.

2.1.1.1. Bus Priority

The arbiters in the main AHB-Lite crossbar implement a two-level bus priority scheme. Priority levels are configured permaster, using the BUS_PRIORITY register in the BUSCTRL register block.

When there are multiple simultaneous accesses to same arbiter, any requests from high-priority masters (priority level 1) will be considered before any requests from low-priority masters (priority 0). If multiple masters of the same priority level attempt to access the same slave simultaneously, a round-robin tie break is applied, i.e. the arbiter grants access to each master in turn.

NOTE

Priority arbitration only applies to multiple masters attempting to access the same slave on the same cycle. Accesses to different slaves, e.g. different SRAM banks, can proceed simultaneously.

When accessing a slave with zero wait states, such as SRAM (i.e. can be accessed once per system clock cycle), highpriority masters will never observe any slowdown or other timing effects caused by accesses from low-priority masters. This allows guaranteed latency and throughput for hard real time use cases; it does however mean a low-priority master may get stalled until there is a free cycle.

2.1.1.2. Bus Performance Counters

The performance counters automatically count accesses to the main AHB-Lite crossbar arbiters. This can assist in diagnosing performance issues, in high-traffic use cases.

There are four performance counters. Each is a 24-bit saturating counter. Counter values can be read from BUSCTRL_PERFCTRx, and cleared by writing any value to BUSCTRL_PERFCTRx. Each counter can count one of the 20 available events at a time, as selected by BUSCTRL_PERFSELx. The available bus events are:

2.1.2. Atomic Register Access

Each peripheral register block is allocated 4kB of address space, with registers accessed using one of 4 methods, selected by address decode.

• Addr + 0x0000 : normal read write access
• Addr + 0x1000 : atomic XOR on write
• Addr + 0x2000 : atomic bitmask set on write
• Addr + 0x3000 : atomic bitmask clear on write

This allows individual fields of a control register to be modified without performing a read-modify-write sequence in software: instead the changes are posted to the peripheral, and performed in-situ. Without this capability, it is difficult to safely access IO registers when an interrupt service routine is concurrent with code running in the foreground, or when the two processors are running code in parallel.

The four atomic access aliases occupy a total of 16kB. Most peripherals on RP2040 provide this functionality natively, and atomic writes have the same timing as normal read/write access. Some peripherals (I2C, UART, SPI and SSI) instead have this functionality added using a bus interposer, which translates upstream atomic writes into downstream read-modify-write sequences, at the boundary of the peripheral. This extends the access time by two system clock cycles.

The SIO (Section 2.3.1), a single-cycle IO block attached directly to the cores' IO ports, does not support atomic accesses at the bus level, although some individual registers (e.g. GPIO) have set/clear/xor aliases.

2.1.3. APB Bridge

The APB bridge interfaces the high-speed main AHB-Lite interconnect to the lower-bandwidth peripherals. Whilst the AHB-Lite fabric offers zero-wait-state access everywhere, APB accesses have a cycle penalty:

• APB bus accesses take two cycles minimum (setup phase and access phase)
• The bridge adds an additional cycle to read accesses, as the bus request and response are registered
• The bridge adds two additional cycles to write accesses, as the APB setup phase can not begin until the AHB-Lite write data is valid

As a result, the throughput of the APB portion of the bus fabric is somewhat lower than the AHB-Lite portion. However, there is more than sufficient bandwidth to saturate the APB serial peripherals.

2.1.4. Narrow IO Register Writes

Memory-mapped IO registers on RP2040 ignore the width of bus read/write accesses. They treat all writes as though they were 32 bits in size. This means software can not use byte or halfword writes to modify part of an IO register: any write to an address where the 30 address MSBs match the register address will affect the contents of the entire

register.

To update part of an IO register, without a read-modify-write sequence, the best solution on RP2040 is atomic set/clear/XOR (see Section 2.1.2). Note that this is more flexible than byte or halfword writes, as any combination of fields can be updated in one operation.

Upon a 8-bit or 16-bit write (such as a strb instruction on the Cortex-M0+), an IO register will sample the entire 32-bit write databus. The Cortex-M0+ and DMA on RP2040 will always replicate narrow data across the bus:

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/system/narrow\_io\_write/narrow\_io\_write.c Lines 19 - 62

int main() {
    stdio_init_all();

    // We'll use WATCHDOG_SCRATCH0 as a convenient 32 bit read/write register
    // that we can assign arbitrary values to
    io_rw_32 *scratch32 = &watchdog_hw->scratch[0];
    // Alias the scratch register as two halfwords at offsets +0x0 and +0x2
    volatile uint16_t *scratch16 = (volatile uint16_t *) scratch32;
    // Alias the scratch register as four bytes at offsets +0x0, +0x1, +0x2, +0x3:
    volatile uint8_t *scratch8 = (volatile uint8_t *) scratch32;

    // Show that we can read/write the scratch register as normal:
    printf("Writing 32 bit value\n");
    *scratch32 = 0xdeadbeef;
    printf("Should be 0xdeadbeef: 0x%08x\n", *scratch32);

    // We can do narrow reads just fine -- IO registers treat this as a 32 bit
    // read, and the processor/DMA will pick out the correct byte lanes based
    // on transfer size and address LSBs
    printf("\nReading back 1 byte at a time\n");
    // Little-endian!
    printf("Should be ef be ad de: %02x ", scratch8[0]);
    printf("%02x ", scratch8[1]);
    printf("%02x ", scratch8[2]);
    printf("%02x\n", scratch8[3]);

    // Byte writes are replicated four times across the 32-bit bus, and IO
    // registers usually sample the entire write bus.
    printf("\nWriting 8 bit value 0xa5 at offset 0\n");
    scratch8[0] = 0xa5;
    // Read back the whole scratch register in one go
    printf("Should be 0xa5a5a5a5: 0x%08x\n", *scratch32);

    // The IO register ignores the address LSBs [1:0] as well as the transfer
    // size, so it doesn't matter what byte offset we use
    printf("\nWriting 8 bit value at offset 1\n");
    scratch8[1] = 0x3c;
    printf("Should be 0x3c3c3c3c: 0x%08x\n", *scratch32);

    // Halfword writes are also replicated across the write data bus
    printf("\nWriting 16 bit value at offset 0\n");
    scratch16[0] = 0xf00d;
    printf("Should be 0xf00df00d: 0x%08x\n", *scratch32);
} 

2.1.5. List of Registers

The Bus Fabric registers start at a base address of 0x40030000 (defined as BUSCTRL_BASE in SDK).

Table 4. List of BUSCTRL registers

BUSCTRL: BUS_PRIORITY Register

Offset: 0x00

Description

Set the priority of each master for bus arbitration.

Table 5. BUS_PRIORITY Register

BUSCTRL: BUS_PRIORITY_ACK Register

Offset: 0x04

Description

Bus priority acknowledge

Table 6. BUS PRIORITY ACK Register

BUSCTRL: PERFCTR0 Register

Offset: 0x08

Description

Bus fabric performance counter 0
Table 7. PERFCTR0 Register

BUSCTRL: PERFSEL0 Register

Offset: 0x0c

Description

Bus fabric performance event select for PERFCTR0
Table 8. PERFSEL0 Register

BUSCTRL: PERFCTR1 Register

Offset: 0x10

Description

Bus fabric performance counter 1

Table 9. PERFCTR1 Register

BUSCTRL: PERFSEL1 Register

Offset: 0x14

Description

Bus fabric performance event select for PERFCTR1

Table 10. PERFSEL1 Register

BUSCTRL: PERFCTR2 Register

Offset: 0x18

Description

Bus fabric performance counter 2

Table 11. PERFCTR2 Register

BUSCTRL: PERFSEL2 Register

Offset: 0x1c

Description

Bus fabric performance event select for PERFCTR2

Table 12. PERFSEL2 Register

BUSCTRL: PERFCTR3 Register

Offset: 0x20

Description

Bus fabric performance counter 3

Table 13. PERFCTR3 Register

BUSCTRL: PERFSEL3 Register

Offset: 0x24

Description

Bus fabric performance event select for PERFCTR3

Table 14. PERFSEL3 Register

2.2. Address Map

The address map for the device is split in to sections as shown in Table 15. Details are shown in the following sections. Unmapped address ranges raise a bus error when accessed.

2.2.1. Summary

Table 15. Address Map Summary

2.2.2. Detail

ROM:

XIP:

SRAM. SRAM0-3 striped:

SRAM 4-5 are always non-striped:

Non-striped aliases of SRAM0-3:

APB Peripherals:

AHB-Lite peripherals:

USB has a DPRAM at its base followed by registers:

Remaining AHB-Lite peripherals:

IOPORT Peripherals:

Cortex-M0+ Internal Peripherals:

2.3. Processor subsystem

The RP2040 processor subsystem consists of two Arm Cortex-M0+ processors — each with its standard internal Arm CPU peripherals — alongside external peripherals for GPIO access and inter-core communication. Details of the Arm Cortex-M0+ processors, including the specific feature configuration used on RP2040, can be found in Section 2.4.

Figure 6. Two Cortex-M0+ processors, each with a dedicated 32-bit AHB-Lite bus port, for code fetch, loads and stores. The SIO is connected to the single-cycle IOPORT bus of each processor, and provides GPIO access, two-way communications, and other core-local peripherals. Both processors can be debugged via a single multi-drop Serial Wire Debug bus. 26 interrupts (plus NMI) are routed to the NVIC and WIC on each processor.

graph TD
    A["From peripherals"] --> B["Interrupts"]
    C["From external debugger"] --> D["Serial Wire Debug"]
    B --> E["NVIC"]
    B --> F["DAP"]
    D --> G["Core 0 Cortex-M0+"]
    D --> H["Core 1 Cortex-M0+"]
    E --> I["Bus Interface"]
    F --> J["Bus Interface"]
    G --> K["SIO"]
    H --> L["AHB-Lite"]
    I --> M["To bus fabric"]
    J --> N["To GPIO Muxing"]
    K --> O["IAOPT"]
    L --> P["AHB-Lite"]
    M --> Q["GPIO ×36"]
    N --> R["To bus fabric"]
    O --> S["To bus fabric"]
    P --> T["IAOPT"]
    Q --> U["GPIO ×36"]
    R --> V["TO bus fabric"]
    S --> W["IAOPT"]
    T --> X["TO bus fabric"]
    U --> Y["IAOPT"]
    V --> Z["TO bus fabric"]
    W --> AA["IAOPT"]
    X --> AB["TO bus fabric"]
    Y --> AC["IAOPT"]

 NOTE

The terms core0 and core1, proc0 and proc1 are used interchangeably in RP2040’s registers and documentation to refer to processor 0, and processor 1 respectively.

The processors use a number of interfaces to communicate with the rest of the system:

• Each processor uses its own independent 32-bit AHB-Lite bus to access memory and memory-mapped peripherals (more detail in Section 2.1)
• The single-cycle IO block provides high-speed, deterministic access to GPIOs via each processor’s IOPORT
• 26 system-level interrupts are routed to both processors
• A multi-drop Serial Wire Debug bus provides debug access to both processors from an external debug host

2.3.1. SIO

The Single-cycle IO block (SIO) contains several peripherals that require low-latency, deterministic access from the processors. It is accessed via each processor’s IOPORT: this is an auxiliary bus port on the Cortex-M0+ which can perform rapid 32-bit reads and writes. The SIO has a dedicated bus interface for each processor’s IOPORT, as shown in Figure 7. Processors access their IOPORT with normal load and store instructions, directed to the special IOPORT address segment, 0xd0000000…0xdfffffff. The SIO appears as memory-mapped hardware within the IOPORT space.

 NOTE

The SIO is not connected to the main system bus due to its tight timing requirements. It can only be accessed by the processors, or by the debugger via the processor debug ports.

Figure 7. The singlecycle IO block contains memorymapped hardware which the processors must be able to access quickly. The FIFOs and spinlocks support message passing and synchronisation between the two cores. The shared GPIO registers provide fast and concurrencysafe direct access to GPIO-capable pins. Some core-local arithmetic hardware can be used to accelerate common tasks on the processors.

graph TD
    A["Core 0"] -->|IOPORT| B["Bus Interface"]
    C["Core 1"] -->|IOPORT| D["Bus Interface"]
    B --> E["CPUID 0"]
    B --> F["CPUID 1"]
    E --> G["FIFO 0 to 1"]
    F --> H["FIFO 1 to 0"]
    G --> I["Hardware Spinlock ×32"]
    H --> I
    I --> J["Integer Divider"]
    I --> K["Integer Divider"]
    J --> L["Interpolator 0"]
    J --> M["Interpolator 1"]
    K --> N["Interpolator 0"]
    K --> O["Interpolator 1"]
    L --> P["GPIO Registers Shared, atomic set/clear/xor"]
    M --> P
    N --> P
    O --> P
    P --> Q["GPIO ×36"]
    Q --> R["To GPIO Muxing"]
    style A fill:#f9f,stroke:#333
    style C fill:#f9f,stroke:#333
    style B fill:#ccf,stroke:#333
    style D fill:#ccf,stroke:#333

All IOPORT reads and writes (and therefore all SIO accesses) take place in exactly one cycle, unlike the main AHB-Lite system bus, where the Cortex-M0+ requires two cycles for a load or store, and may have to wait longer due to contention from other system bus masters. This is vital for interfaces such as GPIO, which have tight timing requirements.

SIO registers are mapped to word-aligned addresses in the range 0xd0000000…0xd000017c. The remainder of the IOPORT space is reserved for future use.

The SIO peripherals are described in more detail in the following sections.

2.3.1.1. CPUID

The register CPUID is the first register in the IOPORT space. Core 0 reads a value of 0 when accessing this address, and core 1 reads a value of 1. This is a convenient method for software to determine on which core it is running. This is checked during the initial boot sequence: both cores start running simultaneously, core 1 goes into a deep sleep state, and core 0 continues with the main boot sequence.

 IMPORTANT

CPUID should not be confused with the Cortex-M0+ CPUID register (Section 2.4.4.1.1) on each processor’s internal Private Peripheral Bus, which lists the processor’s part number and version.

2.3.1.2. GPIO Control

The processors have access to GPIO registers for fast and direct control of pins with GPIO functionality. There are two identical sets of registers:

• GPIO_x for direct control of IO bank 0 (user GPIOs 0 to 29, starting at the LSB)
• GPIO_HI_x for direct control of the QSPI IO bank (in the order SCLK, SSn, SD0, SD1, SD2, SD3, starting at the LSB)

NOTE

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

These GPIO registers are shared between the two cores, and both cores can access them simultaneously. There are three registers for each bank:

• Output registers, GPIO_OUT and GPIO_HI_OUT, are used to set the output level of the GPIO (1/0 for high/low)
• Output enable registers, GPIO_OE and GPIO_HI_OE, are used to enable the output driver. 0 for high-impedance, 1 for drive high/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 all 30 GPIO values (or 6 for GPIO_HI_IN) in a single read. Software can then mask 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 859 - 869

859 static inline bool gpio_get(uint gpio) {
860 #ifdef NUM_BANK0_GPIOS <= 32
861    return sio_hw->gpio_in & (1u << gpio);
862 #else
863    if (gpio < 32) {
864    return sio_hw->gpio_in & (1u << gpio);
865    } else {
866    return sio_hw->gpio_hi_in & (1u << (gpio - 32));
867    }
868 #endif
869 } 

The OUT and OE registers also have atomic SET, CLR, and XOR aliases, which allows software to update a subset of the pins in one operation. This is vital not only for safe parallel GPIO access between the two cores, but also safe concurrent GPIO access in an interrupt handler and foreground code running on one core.

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2\_common/hardware\_gpio/include/hardware/gpio.h Lines 908 - 914

908 static inline void gpio_set_mask(uint32_t mask) {
909 #ifdef PICO_USE_GPIO_COPROCESSOR
910    gpio_clo_out_set(mask);
911 #else
912    sio_hw->gpio_set = mask;
913 #endif
914 } 

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2\_common/hardware\_gpio/include/hardware/gpio.h Lines 955 - 961

955 static inline void gpio_clr_mask(uint32_t mask) {
956 #ifdef PICO_USE_GPIO_COPROCESSOR
957    gpio_clr(_mask);
958 #else
959    sio_hw->gpio_clr = mask;
960 #endif
961 } 

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2\_common/hardware\_gpio/include/hardware/gpio.h Lines 1145 - 1170

1145 static inline void gpio_put(uint gpio, bool value) {
1146 #ifdef PICO_USE_GPIO_COPROCESSOR
1147    gpio_bit_out_put(gpio, value);
1148 #elif NUM_BANK0_GPIOS <= 32
1149    uint32_t mask = 1ul << gpio;
1150    if (value)
1151    gpio_set_mask(mask);
1152    else
1153    gpio_clr_mask(mask);
1154 #else
1155    uint32_t mask = 1ul << (gpio & 0x1fu);
1156    if (gpio < 32) {
1157    if (value) {
1158    sio_hw->gpio_set = mask;
1159    } else {
1160    sio_hw->gpio_clr = mask;
1161    }
1162    } else {
1163    if (value) {
1164    sio_hw->gpio_hi_set = mask;
1165    } else {
1166    sio_hw->gpio_hi_clr = mask;
1167    }
1168 }
1169 #endif
1170 } 

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, and core 1 wrote immediately afterward. For example, if core 0 SETs a bit, and core 1 simultaneously XORs it, the bit will be set to 0, irrespective of it original value.

 NOTE

This is a conceptual model for the result that is produced when two cores write to a GPIO register simultaneously. The register does not actually contain this intermediate value 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 without any positive glitch.

2.3.1.3. 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 nonzero 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 be successful.

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

2.3.1.4. 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 eight 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, mapped to system IRQ numbers 15 and 16. 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. The ROE and WOF flags are cleared by writing any value to FIFO_ST, and the VLD flag is cleared by reading data from the FIFO until empty.

If the corresponding interrupt line is enabled in the Cortex-M0+ NVIC, then the processor will take an interrupt each time data appears in its FIFO, or if it has performed some invalid FIFO operation (read on empty, write on full). Typically Core 0 will use IRQ15 and core 1 will use IRQ16. If the IRQs are used the other way round then it is difficult for the core that has been interrupted to correctly identify the reason for the interrupt as the core doesn’t have access to the other core’s FIFO status register.

 NOTE

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

The inter-processor FIFOs and the Cortex-M0+ Event signals are used by the bootrom (Section 2.8) 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.

2.3.1.5. Integer Divider

The SIO provides one 8-cycle signed/unsigned divide/modulo module to each of the cores. Calculation is started by writing a dividend and divisor to the two argument registers, DIVIDEND and DIVISOR. The divider calculates the quotient / and remainder % of this division over the next 8 cycles, and on the 9th cycle the results can be read from the two result registers DIV_QUOTIENT and DIV_REMAINDER. A 'ready' bit in register DIV_CSR can be polled to wait for the calculation to complete, or software can insert a fixed 8-cycle delay.

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2\_common/hardware\_divider/divider.S Lines 12 - 16

12 regular_func_with_section hw_divider_divmod_s32
13 ldr r3, = (SIO_BASE)
14 str r0, [r3, #SIO_DIV_SDIVIDEND_OFFSET]
15 str r1, [r3, #SIO_DIV_SDIVISOR_OFFSET]
16 b hw_divider_divmod_return 

NOTE

Software is free to perform other non-divider operations during these 8 cycles.

There are two aliases of the operand registers: writing to the signed alias (DIV_SDIVIDEND and DIV_SDIVISOR) will initiate a signed calculation, and the other (DIV_UDIVIDEND and DIV_UDIVISOR) will initiate an unsigned calculation.

SDK: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2\_common/hardware\_divider/divider.S Lines 20 - 24

20 regular_func_with_section hw_divider_divmod_u32
21 ldr r3, = (SIO_BASE)
22 str r0, [r3, #SIO_DIV_UDIVIDEND_OFFSET]
23 str r1, [r3, #SIO_DIV_UDIVISOR_OFFSET]
24 b hw_divider_divmod_return 

NOTE

A new calculation begins immediately with every write to an operand register, and a new operand write immediately squashes any calculation currently in progress. For example, when dividing many numbers by the same divisor, only xDIVISOR needs to be written, and the signedness of each calculation is determined by whether SDIVIDEND or UDIVIDEND is written.

To support save and restore on interrupt handler entry/exit (or on e.g. an RTOS context switch), the result registers are also writable. Writing to a result register will cancel any operation in progress at the time. The DIV_CSR.DIRTY flag can help make save/restore more efficient: this flag is set when any divider register (operand or result) is written to, and cleared when the quotient is read.

NOTE

When enabled, the default divider AEABI support maps C level / and % to the hardware divider. When building software using the SDK and using the divider directly, it is important to read the quotient register last. This ensures the partial divider state will be correctly saved and restored by any interrupt code that uses the divider. You should read the quotient register whether you need the value or not.

The SDK module pico_divider https://github.com/raspberrypi/pico-sdk/blob/master/src/common/ pico_divider_headers/include/pico/divider.h provides both the AEABI implementation needed to hook the C / and % operators for both 32-bit and 64-bit integer division, as well as some additional C functions that return quotients and remainders at the same time. All of these functions correctly save and restore the hardware divider state (when dirty) so that they can be used in either user or IRQ handler code.

The SDK module hardware_divider https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2\_common/ hardware_divider/include/hardware/divider.h provides lower level macros and helper functions for accessing the hardware_divider, but these do not save and restore the hardware divider state (although this header does provide separate functions to do so).

2.3.1.6. Interpolator

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

The interpolators are used to accelerate audio operations within the SDK, but their flexible configuration makes it possible to optimise many other tasks such as quantization and dithering, table lookup address generation, affine texture mapping, decompression and linear feedback.

Figure 8. An interpolator. The two accumulator registers and three base registers have singlecycle 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, ADD_RAW.

graph TD
    A["Result 0"] --> B["0"]
    C["Result 1"] --> D["1"]
    B --> E["Accumulator 0"]
    D --> F["Accumulator 1"]
    E --> G["0"]
    F --> H["0"]
    G --> I["Right Shift"]
    H --> J["Mask"]
    I --> K["Sign-extend fromMask"]
    J --> L["1"]
    K --> M["0"]
    L --> N["1"]
    M --> O["+"]
    N --> P["0"]
    Q["Result 0"] --> R["1"]
    S["Result 1"] --> T["0"]
    U["Result 2"] --> V["1"]
    W["Result 1"] --> X["0"]
    Y["Result 2"] --> Z["1"]
    AA["Result 0"] --> AB["1"]
    AC["Result 1"] --> AD["0"]
    AE["Result 2"] --> AF["1"]

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. This can be used to advance the state of interpolator each time a result is read.

Additionally the interpolator supports simple fractional blending between two values as well as clamping values such that they lie 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

void times_table() {
    puts("9 times table:");
    // Initialise lane 0 on interp0 on this core
    interp_config cfg = interp_default_config();
    interp_set_config(interp0, 0, &cfg);
    interp0->accum[0] = 0;
    interp0->base[0] = 9;
    for (int i = 0; i < 10; ++i)
    printf("%d\n", interp0->pop[0]);
} 

 NOTE

By sheer coincidence, the interpolators are extremely well suited to SNES MODE7-style graphics routines. For example, on each core, INTERP0 can provide a stream of tile lookups for some affine transform, and INTERP1 can provide offsets into the tiles for the same transform.

2.3.1.6.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 produces 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, ADD_RAW.

graph LR
    A["Result 0"] --> B["0"]
    C["Result 1"] --> D["1"]
    B --> E["Accumulator 0"]
    D --> F["Accumulator 1"]
    E --> G["0"]
    F --> H["0"]
    G --> I["1"]
    H --> J["Right Shift"]
    I --> J
    J --> K["Mask"]
    K --> L["Sign-extend fromMask"]
    L --> M["1"]
    M --> N["0"]
    N --> O["1"]
    O --> P["Add to BASE1 (for PEEK0/POP0)"]
    N --> Q["Add to BASE2 (forms part of PEEK2/POP2)"]

Each lane performs these three operations, in sequence:

• A right shift by CTRL_LANEx_SHIFT (0 to 31 bits)
• A mask of bits from CTRL_LANEx_MASK_LSB to CTRL_LANEx_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_LANEx_MASK_MSB and OR it into all more-significant bits, if CTRL_LANEx_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

void moving_mask() {
    interp_config cfg = interp_default_config();
    interp0->accum[0] = 0x1234abcd;

    puts("Masking:");
    printf("ACCUM0 = %08x\n", interp0->accum[0]);
    for (int i = 0; i < 8; ++i) {
    // LSB, then MSB. These are inclusive, so 0,31 means "the entire 32 bit register"
    interp_config_set_mask(&cfg, i * 4, i * 4 + 3);
    interp_set_config(interp0, 0, &cfg);
    // Reading from ACCUMx_ADD returns the raw lane shift and mask value, without BASEx added
    printf("Nibble %d: %08x\n", i, interp0->add_raw[0]);
    }

    puts("Masking with sign extension:");
    interp_config_set_signed(&cfg, true);
    for (int i = 0; i < 8; ++i) {
    interp_config_set_mask(&cfg, i * 4, i * 4 + 3);
    interp_set_config(interp0, 0, &cfg);
    printf("Nibble %d: %08x\n", i, interp0->add_raw[0]);
    }
} 

The above example should print:

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: ffffffffd
Nibble 1: fffffffc0
Nibble 2: ffffffb00
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 e.g. 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:

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 

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

$$
x = x _ {0} + \alpha (x _ {1} - x _ {0}), \mathrm{for} 0 \leq \alpha < 1
$$

Where is the register BASE0, is the register BASE1, and is a fractional value formed from the least significant 8 bits of the lane 1 shift and mask value.

Blend mode has the following differences from normal mode:

• 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

void simple_blend1() {
    puts("Simple blend 1:");
    interp_config cfg = interp_default_config();
    interp_config_set_blend(&cfg, true);
    interp_set_config(interp0, 0, &cfg);
    cfg = interp_default_config();
    interp_set_config(interp0, 1, &cfg);
    interp0->base[0] = 500;
    interp0->base[1] = 1000;
    for (int i = 0; i <= 6; i++) {
    // set fraction to value between 0 and 255
    interp0->accum[1] = 255 * i / 6;
    // ≈ 500 + (1000 - 500) * i / 6;
    printf("%d\n", (int) interp0->peek[1]);
    }
} 

This should print (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

void print_simple_blend2_results(bool is_signed) {
    // lane 1 signed flag controls whether base 0/1 are treated as signed or unsigned
    interp_config cfg = interp_default_config();
    interp_config_set_signed(&cfg, is_signed);
    interp_set_config(interp0, 1, &cfg);

    for (int i = 0; i <= 6; i++) {
    interp0->accum[1] = 255 * i / 6;
    if (is_signed) {
    printf("%d\n", (int) interp0->peek[1]);
    } else {
    printf("0x%08x\n", (uint) interp0->peek[1]);
    }
    }
}

void simple_blend2() {
    puts("Simple blend 2:");
    interp_config cfg = interp_default_config();
    interp_config_set_blend(&cfg, true);
    interp_set_config(interp0, 0, &cfg);

    interp0->base[0] = (uint32_t) -1000;
    interp0->base[1] = 1000;

    puts("signed:");
    print_simple_blend2_results(true);

    puts("unsigned:");
    print_simple_blend2_results(false);
} 

This should print:

signed:
-1000
-672
-336
-8
328
656
992
unsigned:
0xfffffc18
0xd5fffd60
0xaafffeb0
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:

0x00004000
0x0000e800
0xfffffe800 

2.3.1.6.3. Clamp Mode

Clamp mode is available on INTERP1 on each core, and is enabled by the CTRL_LANE0_CLAMP control flag. 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 greater than BASE1, a value of BASE1 is produced; if less than BASE0, a value of BASE0 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:

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

2.3.1.6.4. Sample Use Case: Linear Interpolation

Linear interpolation is a more complete example of using blend mode in conjunction with other interpolator functionality:

In this example, ACCUM0 is used to track 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

void linear_interpolation() {
    puts("Linear interpolation:");
    const int uv_fractional_bits = 12;
    // for lane 0
    // shift and mask XXXX XXXX XXXX XXXX XXXX FFFF FFFF FFFF (accum 0)
    // to    0000 0000 000X XXXX XXXX XXXX XXX0
    // i.e. non fractional part times 2 (for uint16_t)
    interp_config cfg = interp_default_config();
    interp_config_set_shift(&cfg, uv_fractional_bits - 1);
    interp_config_set_mask(&cfg, 1, 32 - uv_fractional_bits);
    interp_config_set_blend(&cfg, true);
    interp_set_config(interp0, 0, &cfg);

    // for lane 1
    // shift XXXX XXXX XXXX XXXX XXXX FFFF FFFF FFFF (accum 0 via cross input)
    // to    0000 XXXX XXXX XXXX XXXF FFFF FFFF

    cfg = interp_default_config();
    interp_config_set_shift(&cfg, uv_fractional_bits - 8);
    interp_config_set_signed(&cfg, true);
    interp_config_set_cross_input(&cfg, true); // signed blending
    interp_set_config(interp0, 1, &cfg);

    int16_t samples[] = {0, 10, -20, -1000, 500};

    // step is 1/4 in our fractional representation 

uint step = (1 << uv_fractional_bits) / 4;
interp0->accum[0] = 0; // initial sample_offset;
interp0->base[2] = (uintptr_t) samples;
for (int i = 0; i < 16; i++) {
    // result2 = samples + (lane0 raw result)
    // i.e. ptr to the first of two samples to blend between
    int16_t *sample_pair = (int16_t *) interp0->peek[2];
    interp0->base[0] = sample_pair[0];
    interp0->base[1] = sample_pair[1];
    uint32_t peek1 = interp0->peek[1];
    uint32_t add_raw1 = interp0->add_raw[1];
    printf("%d\t(%d%% between %d and %d)\n", (int) peek1,
    100 * (add_raw1 & 0xff) / 0xff,
    sample_pair[0], sample_pair[1]);
    interp0->add_raw[0] = step;
} 

This should print:

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

2.3.1.6.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 part of the texture coordinates are used to form an address within the texture to lookup a pixel colour.

By using two lanes, all three base values and the CTRL_LANEx_ADD_RAW flag, it is possible to reduce what would be quite an expensive CPU operation to a single cycle iteration using the interpolator.

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:

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

2.3.1.7. List of Registers

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

Table 16. List of SIO registers

SIO: CPUID Register

Offset: 0x000

Description

Processor core identifier

Table 17. CPUID Register

SIO: GPIO_IN Register

Offset: 0x004

Description

Input value for GPIO pins

Table 18. GPIO_IN Register

SIO: GPIO_HI_IN Register

Offset: 0x008

Description

Input value for QSPI pins

Table 19. GPIO_HI_IN Register

SIO: GPIO_OUT Register

Offset: 0x010

Description

GPIO output value

Table 20. GPIO_OUT Register

SIO: GPIO_OUT_SET Register

Offset: 0x014

Description

GPIO output value set

Table 21. GPIO_OUT_SET Register

SIO: GPIO_OUT_CLR Register

Offset: 0x018

Description

GPIO output value clear

Table 22. GPIO_OUT_CLR Register

SIO: GPIO_OUT_XOR Register

Offset: 0x01c

Description

GPIO output value XOR

Table 23. GPIO_OUT_XOR Register

SIO: GPIO_OE Register

Offset: 0x020

Description

GPIO output enable

Table 24. GPIO_OE Register

SIO: GPIO_OE_SET Register

Offset: 0x024

Description

GPIO output enable set

SIO: GPIO_OE_CLR Register

Offset: 0x028

Description

GPIO output enable clear

SIO: GPIO_OE_XOR Register

Offset: 0x02c

Description

GPIO output enable XOR

SIO: GPIO_HI_OUT Register

Offset: 0x030

Description

QSPI output value

SIO: GPIO_HI_OUT_SET Register

Offset: 0x034

Description

QSPI output value set

Table 29. GPIO_HI_OUT_SET Register

SIO: GPIO_HI_OUT_CLR Register

Offset: 0x038

Description

QSPI output value clear

Table 30. GPIO_HI_OUT_CLR Register

SIO: GPIO_HI_OUT_XOR Register

Offset: 0x03c

Description

QSPI output value XOR

Table 31. GPIO_HI_OUT_XOR Register

SIO: GPIO_HI_OE Register

Offset: 0x040

Description

QSPI output enable

Table 32. GPIO_HI_OE Register

SIO: GPIO_HI_OE_SET Register

Offset: 0x044

Description

QSPI output enable set

Table 33. GPIO_HI_OE_SET Register

SIO: GPIO_HI_OE_CLR Register

Offset: 0x048

Description

QSPI output enable clear

Table 34. GPIO_HI_OE_CLR Register

SIO: GPIO_HI_OE_XOR Register

Offset: 0x04c

Description

QSPI output enable XOR

Table 35. 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 36. FIFO_ST Register

SIO: FIFO_WR Register

Offset: 0x054

Table 37. FIFO_WR Register

SIO: FIFO_RD Register

Offset: 0x058

Table 38. FIFO_RD Register

SIO: SPINLOCK_ST Register

Offset: 0x05c

Table 39. SPINLOCK_ST Register

SIO: DIV_UDIVIDEND Register

Offset: 0x060

Table 40. DIV_UDIVIDEND Register

SIO: DIV_UDIVISOR Register

Offset: 0x064

SIO: DIV_SDIVIDEND Register

Offset: 0x068

SIO: DIV_SDIVISOR Register

Offset: 0x06c

SIO: DIV_QUOTIENT Register

Offset: 0x070

SIO: DIV_REMAINDER Register

Offset: 0x074

SIO: DIV_CSR Register

Offset: 0x078

Description

Control and status register for divider.

SIO: INTERP0_ACCUM0 Register

Offset: 0x080

SIO: INTERP0_ACCUM1 Register

Offset: 0x084

SIO: INTERP0_BASE0 Register

Offset: 0x088

SIO: INTERP0_BASE1 Register

Offset: 0x08c

SIO: INTERP0_BASE2 Register

Offset: 0x090

SIO: INTERP0_POP_LANE0 Register

Offset: 0x094

SIO: INTERP0_POP_LANE1 Register

Offset: 0x098

SIO: INTERP0_POP_FULL Register

Offset: 0x09c

SIO: INTERP0_PEEK_LANE0 Register

Offset: 0x0a0

SIO: INTERP0_PEEK_LANE1 Register

Offset: 0x0a4

SIO: INTERP0_PEEK_FULL Register

Offset: 0x0a8

SIO: INTERP0_CTRL_LANE0 Register

Offset: 0x0ac

Description

Control register for lane 0

SIO: INTERP0_CTRL_LANE1 Register

Offset: 0x0b0

Description

Control register for lane 1

SIO: INTERP0_ACCUM0_ADD Register

Offset: 0x0b4

SIO: INTERP0_ACCUM1_ADD Register

Offset: 0x0b8

SIO: INTERP0_BASE_1AND0 Register

Offset: 0x0bc

SIO: INTERP1_ACCUM0 Register

Offset: 0x0c0

SIO: INTERP1_ACCUM1 Register

Offset: 0x0c4

SIO: INTERP1_BASE0 Register

Offset: 0x0c8

SIO: INTERP1_BASE1 Register

Offset: 0x0cc

SIO: INTERP1_BASE2 Register

Offset: 0x0d0

SIO: INTERP1_POP_LANE0 Register

Offset: 0x0d4

SIO: INTERP1_POP_LANE1 Register

Offset: 0x0d8

SIO: INTERP1_POP_FULL Register

Offset: 0x0dc

SIO: INTERP1_PEEK_LANE0 Register

Offset: 0x0e0

SIO: INTERP1_PEEK_LANE1 Register

Offset: 0x0e4

SIO: INTERP1_PEEK_FULL Register

Offset: 0x0e8

SIO: INTERP1_CTRL_LANE0 Register

Offset: 0x0ec
Description
Control register for lane 0

SIO: INTERP1_CTRL_LANE1 Register

Offset: 0x0f0

Description

Control register for lane 1

Table 75. INTERP1_CTRL_LANE 1 Register

SIO: INTERP1_ACCUM0_ADD Register

Offset: 0x0f4

Table 76. INTERP1_ACCUM0_AD D Register

SIO: INTERP1_ACCUM1_ADD Register

Offset: 0x0f8

Table 77. INTERP1_ACCUM1_AD D Register

SIO: INTERP1_BASE_1AND0 Register

Offset: 0x0fc

Table 78. INTERP1_BASE_1AND 0 Register

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

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

Table 79. SPINLOCK0, SPINLOCK1, …, SPINLOCK30, SPINLOCK31 Registers

2.3.2. Interrupts

Each core is equipped with a standard ARM Nested Vectored Interrupt Controller (NVIC) which has 32 interrupt inputs. Each NVIC has the same interrupts routed to it, with the exception of the GPIO interrupts: there is one GPIO interrupt per bank, per core. These are completely independent, so e.g. core 0 can be interrupted by GPIO 0 in bank 0, and core 1 by GPIO 1 in the same bank.

On RP2040, only the lower 26 IRQ signals are connected on the NVIC, and IRQs 26 to 31 are tied to zero (never firing). The core can still be forced to enter the relevant interrupt handler by writing bits 26 to 31 in the NVIC ISPR register.

Table 80. Interrupts

 NOTE

XIP_IRQ is from the SSI block that makes up part of the XIP block. It could be used in a configuration where code is running from SRAM instead of flash. In this configuration, the XIP block could be used as a normal SSI peripheral.

Nested interrupts are supported in hardware: a lower-priority interrupt can be preempted by a higher-priority interrupt (or another exception e.g. HardFault), and the lower-priority interrupt will resume once higher-priority exceptions have completed. The priority order is determined by:

• First, the dynamic priority level configured per interrupt by the NVIC_IPR0-7 registers. The Cortex-M0+ implements the two most significant bits of an 8-bit priority field, so four priority levels are available, and the numerically-lowest level (level 0) is the highest priority.
• Second, for interrupts with the same dynamic priority level, the lower-numbered IRQ has higher priority (using the IRQ numbers given in the table above).

Some care has gone into arranging the RP2040 interrupt table to give a sensible default priority ordering, but individual interrupts can be raised or lowered in priority, using NVIC_IPR0 through NVIC_IPR7, to suit a particular use case.

The 26 system IRQ signals are masked (NMI mask) and then ORed together creating the NMI signal for the core. The NMI mask for each core can be configured using PROC0_NMI_MASK and PROC1_NMI_MASK in the Syscfg register block. Each of these registers has one bit for each system interrupt, and the each core’s NMI is asserted if a system interrupt is asserted and the corresponding NMI mask bit is set for that core.

CAUTION

If the watchdog is armed, and some bits are set on the core 1 NMI mask, the RESETS block (and hence Syscfg) should be included in the watchdog reset list. Otherwise, following a watchdog event, core 1 NMI may be asserted when the core enter the bootrom. It is safe for core 0 to take an NMI when entering the bootrom (the handler will clear the NMI mask).

2.3.3. Event Signals

The Cortex-M0+ can enter a sleep state until an "event" (or interrupt) takes place, using the WFE instruction. It can also generate events, using the SEV instruction. On RP2040 the event signals are cross-wired between the two processors, so that an event sent by one processor will be received on the other.

NOTE

The event flag is "sticky", so if both processors send an event (SEV) simultaneously, and then both go to sleep (WFE), they will both wake immediately, rather than getting stuck in a sleep state.

While in a WFE (or WFI) sleep state, the processor can shut off its internal clock gates, consuming much less power. When both processors are sleeping, and the DMA is inactive, RP2040 as a whole can enter a sleep state, disabling clocks on unused infrastructure such as the busfabric, and waking automatically when one of the processors wakes. See Section 2.11.2.

2.3.4. Debug

The 2-wire Serial Wire Debug (SWD) port 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 Arm debug functionality
• Access to processor architectural state
• Access to memory and memory-mapped IO via the system bus

The SWD bus is exposed on two dedicated pins and is immediately available after power-on.

NOTE

We recommend a max SWD frequency of 24MHz. This depends heavily on your setup. You may need to run much slower (1MHz) depending on the quality and length of your cables.

Debug access is via independent DAPs (one per core) attached to a shared multidrop SWD bus (SWD v2). Each DAP will only respond to debug commands if correctly addressed by a SWD TARGETSEL command; all others tristate their outputs. Additionally, a Rescue DP (see Section 2.3.4.2) is available which is connected to system control features. Default addresses of each debug port are given below:

• Core 0: 0x01002927
Core 1: 0x11002927
• Rescue DP: 0xf1002927

The Instance IDs (top 4 bits of ID above) can be changed via a sysconfig register which may be useful in a multichip application. However note that ID=0xf is reserved for the internal Rescue DP (see Section 2.3.4.2).

Figure 10. RP2040 Debugging

graph TD
    A["SWCLK"] --> B["IO"]
    C["SWDO"] --> B
    B --> D["SWD Multidrop arbiter"]
    D --> E["SWD"]
    E --> F["Rescue DP"]
    F --> G["pam_restart"]
    H["sys_cfg proc0_dap_instid"] --> I["DAP_0 DP-0 AP"]
    I --> J["Core0"]
    K["sys_cfg proc1_dap_instid"] --> L["DAP_1 DP-1 AP"]
    L --> M["Core1"]
    N["Processors"] --> O["Core0"]
    N --> P["Core1"]
    Q["SWD"] --> R["SWD"]
    R --> S["DAP_0"]
    R --> T["DAP_1"]

2.3.4.1. Software control of SWD pins

The SWD pins for Core 0 and Core 1 can be bit-banged via registers in syscfg (see DBGFORCE). This means that Core 1 could run a USB application that allows debug of Core 0, or similar.

2.3.4.2. Rescue DP

The Rescue DP (debug port) is available over the SWD bus and is only intended for use in the specific case where the chip has locked up, for example if code has been programmed into flash which permanently halts the system clock: in such a case, the normal debugger can not communicate with the processors to return the system to a working state, so more drastic action is needed. A rescue is invoked by setting the CDBGPWRUPREQ bit in the Rescue DP’s CTRL/STAT register.

This causes a hard reset of the chip (functionally similar to a power-on-reset), and sets a flag in the Chip Level Reset block 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.

For a practical example of using the Rescue DP, see the Hardware design with RP2040 book.

2.4. Cortex-M0+

ARM Documentation

Excerpted from the Cortex-M0+ Technical Reference Manual. Used with permission.

The ARM Cortex-M0+ processor is a very low gate count, highly energy efficient processor that is intended for microcontroller and deeply embedded applications that require an area optimized, low-power processor.

2.4.1. Features

The ARM Cortex-M0+ processor features and benefits are:

• Tight integration of system peripherals reduces area and development costs.
• Thumb instruction set combines high code density with 32-bit performance.
• Support for single-cycle I/O access.
• Power control optimization of system components.
• Integrated sleep modes for low-power consumption.

• Fast code execution enables running the processor with a slower clock or increasing sleep mode time.

• Optimized code fetching for reduced flash and ROM power consumption.
• Hardware multiplier.
• Deterministic, high-performance interrupt handling for time-critical applications.
• Deterministic instruction cycle timing.
• Support for system level debug authentication.
• Serial Wire Debug reduces the number of pins required for debugging.

2.4.1.1. Interfaces

The interfaces included in the processor for external access include:

• External AHB-Lite interface to busfabric
• Debug Access Port (DAP)
• Single-cycle I/O Port to SIO peripherals

2.4.1.2. Configuration

Each processor is configured with the following features:

• Architectural clock gating (for power saving)
• Little Endian bus access
• Four Breakpoints
• Debug support (via 2-wire debug pins SWD/SWCLK)
• 32-bit instruction fetch (to match 32-bit data bus)
• IOPORT (for low latency access to local peripherals (see SIO)
• 26 interrupts
• 8 MPU regions
• All registers reset on powerup
• Fast multiplier (MULS 32×32 single cycle)
• SysTick timer
• Vector Table Offset Register (VTOR)
• 34 WIC (Wake-up Interrupt Controller) lines (32 IRQ and NMI, RXEV)
• DAP feature: Halt event support
• DAP feature: SerialWire debug interface (protocol 2 with multidrop support)
• DAP feature: Micro Trace Buffer (MTB) is not implemented

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

Each M0+ core has its own interrupt controller which can individually mask out interrupt sources as required. The same interrupts are routed to both M0+ cores.

2.4.1.3. ARM architecture

The processor implements the ARMv6-M architecture profile. See the ARMv6-M Architecture Reference Manual, and for

further details refer to the ARM Cortex M0+ Technical Reference Manual.

2.4.2. Functional Description

2.4.2.1. Overview

The Cortex-M0+ processor is a configurable, multistage, 32-bit RISC processor. It has an AMBA AHB-Lite interface and includes an NVIC component. It also has hardware debug, single-cycle I/O interfacing, and memory-protection functionality. The processor can execute Thumb code and is compatible with other Cortex-M profile processors.

Figure 11 shows the functional blocks of the processor and surrounding blocks.
Figure 11. Cortex M0+ Functional block diagram

graph TD
    A["Clock"] --> B["PMU"]
    B --> C["RESET CTRL"]
    C --> D["Cortex M0+ Core"]
    D --> E["MPU"]
    E --> F["Bus Interface"]
    F --> G["AHB-Lite Master"]
    F --> H["Single cycle IO Port"]
    I["Reset"] --> J["RESET CTRL"]
    J --> C
    K["Interrupts"] --> L["WIC"]
    L --> M["NVIC"]
    M --> N["Breakpoint and watchpoint unit"]
    N --> O["Debugger interface"]
    O --> P["DAP"]
    P --> Q["Serial Wire Debug"]
    R["Cortex-M0+ subsystem"] --> S["Cortex M0+ Core"]
    S --> T["MPU"]
    T --> U["Bus Interface"]
    U --> V["AHB-Lite Master"]
    S --> W["NVIC"]
    W --> X["Breakpoint and watchpoint unit"]
    X --> Y["Debugger interface"]
    Y --> Z["DAP"]
    Z --> AA["Serial Wire Debug"]

2.4.2.2. Features

The M0+ features:

• The ARMv6-M Thumb® instruction set.
• Thumb-2 technology.
• An ARMv6-M compliant 24-bit SysTick timer.
• A 32-bit hardware multiplier. This is the standard single-cycle multiplier
• The ability to have deterministic, fixed-latency, interrupt handling.
• Load/store multiple instructions that can be abandoned and restarted to facilitate rapid interrupt handling.
• C Application Binary Interface compliant exception model. This is the ARMv6-M, C Application Binary Interface (C-ABI) compliant exception model that enables the use of pure C functions as interrupt handlers.
• Low power sleep-mode entry using Wait For Interrupt (WFI), Wait For Event (WFE) instructions, or the return from interrupt sleep-on-exit feature.

2.4.2.3. NVIC features

The Nested Vectored Interrupt Controller (NVIC) features are:

• 26 external interrupt inputs, each with four levels of priority.
• Dedicated Non-Maskable Interrupt (NMI) input (which can be driven from any standard interrupt source)
• Support for both level-sensitive and pulse-sensitive interrupt lines.
• Wake-up Interrupt Controller (WIC), providing ultra-low power sleep mode support.
• Relocatable vector table.

NOTE

The NVIC supports hardware nesting of exceptions, e.g. an interrupt handler may itself be interrupted if a higherpriority interrupt request arrives whilst the handler is running.

Further details available in Section 2.4.5.

2.4.2.4. Debug features

Debug features are:

• Four hardware breakpoints.
• Two watchpoints.
• Program Counter Sampling Register (PCSR) for non-intrusive code profiling.
• Single step and vector catch capabilities.
• Support for unlimited software breakpoints using BKPT instruction.
• Full access to core registers when the processor is halted.

• Non-intrusive access to core peripherals and zero-waitstate system slaves through a compact bus matrix. A debugger can access these devices, including memory, even when the processor is running.

• CoreSight compliant debug access through a Debug Access Port (DAP) supporting Serial Wire debug connections.

2.4.2.4.1. Debug Access Port

The processor is implemented with a low gate count Debug Access Port (DAP). The low gate count Debug Access Port (DAP) provides a Serial Wire debug-port, and connects to the processor slave port to provide full system-level debug access. For more information on DAP, see the ADI v5.1 version of the ARM Debug Interface v5, Architecture Specification

2.4.2.5. MPU features

Memory Protection Unit (MPU) features are:

• Eight user-configurable memory regions.
• Eight sub-region disables per region.
• Execute never (XN) support.
• Default memory map support.

Further details available in Section 2.4.6.

2.4.2.6. AHB-Lite interface

Transactions on the AHB-Lite interface are always marked as non-sequential. Processor accesses and debug accesses share the external interface to external AHB peripherals. The processor accesses take priority over debug accesses. Any vendor-specific components can populate this bus.

NOTE

Instructions are only fetched using the AHB-Lite interface. To optimize performance, the Cortex-M0+ processor fetches ahead of the instruction it is executing. To minimize power consumption, the fetch ahead is limited to a maximum of 32 bits.

2.4.2.7. Single-cycle I/O port

The processor implements a single-cycle I/O port that provides high speed access to tightly-coupled peripherals, such as general-purpose-I/O (GPIO). The port is accessible both by loads and stores from either the processor or the debugger. You cannot execute code from the I/O port.

2.4.2.8. Power Management Unit

Each processor has its own Power Management Unit (PMU) which allows power saving by turning off clocks to parts of the processor core. There are no separate power domains on RP2040.

The PMU runs from the processor clock which is controlled from the chip level clocks block. The PMU can control the following clock domains within the processor:

• A debug clock containing the processor debug resources and the rest of the DAP.
• A system clock containing the NVIC.
• A processor clock containing the core and associated interfaces

Control is limited to clock enable/disable. When enabled, all domains run at the same clock speed.

The PMU also interfaces with the WIC, to ensure that power-down and wake-up behaviours are transparent to software and work with clocking and sleeping requirements. This includes SLEEP or DEEPSLEEP support as controlled in SCR register.

2.4.2.8.1. Power Management

RP2040 ARM Cortex M0+ uses ARMv6-M which supports the use of Wait For Interrupt (WFI) and Wait For Event (WFE) instructions as part of system power management:

WFI provides a mechanism for hardware support of entry to one or more sleep states. Hardware can suspend execution until a wakeup event occurs.

WFE provides a mechanism for software to suspend program execution until a wakeup condition occurs with minimal or no impact on wakeup latency. Both WFI and WFE are hint instructions that might have no effect on program execution. Normally, they are used in software idle loops that resume program execution only after an interrupt or event of interest occurs.

NOTE

Code using WFE and WFI must handle any spurious wakeup events caused by a debug halt or other reasons.

Refer to the SDK and ARMv6-M guide for further information.

2.4.2.8.2. Wait For Event and Send Event

RP2040 can support software-based synchronization to system events using the Send-Event (SEV) and WFE hint instructions. Software can:

• use the WFE instruction to indicate that it is able to suspend execution of a process or thread until an event occurs, permitting hardware to enter a low power state.

• rely on a mechanism that is transparent to software and provides low latency wakeup.

The WFE mechanism relies on hardware and software working together to achieve energy saving. For example, stalling execution of a processor until a device or another processor has set a flag:

• the hardware provides the mechanism to enter the WFE low-power state.
• software enters a polling loop to determine when the flag is set:
• the polling processor issues a WFE instruction as part of a polling loop if the flag is clear.

• an event is generated (hardware interrupt or Send-Event instruction from another processor) when the flag is set.

WFE wake up events

The following events are WFE wake up events:

• the execution of an SEV instruction on the other processor
• any exception entering the pending state if SEVONPEND in the System Control Register is set to 1.
• an asynchronous exception at a priority that preempts any currently active exceptions.
• a debug event with debug enabled.

The Event Register

The Event Register is a single bit register. When set, an Event Register indicates that an event has occurred, since the register was last cleared, that might prevent the processor having to suspend operation on issuing a WFE instruction. The following conditions apply to the Event Register:

• A reset clears the Event Register.
• Any WFE wakeup event, or the execution of an exception return instruction, sets the Event Register.
• A WFE instruction clears the Event Register.
• Software cannot read or write the value of the Event Register directly.

The Send-Event instruction

The Send-Event (SEV) instruction causes an event to be signalled to the other processor. The Send-Event instruction generates a wakeup event.

The Wait For Event instruction

The action of the WFE instruction depends on the state of the Event Register:

• If the Event Register is set, the instruction clears the register and returns immediately.
• If the Event Register is clear the processor can suspend execution and enter a low-power state. It can remain in that state until the processor detects a WFE wakeup event or a reset. When the processor detects a WFE wakeup event, the WFE instruction completes.

WFE wakeup events can occur before a WFE instruction is issued. Software using the WFE mechanism must tolerate spurious wake up events, including multiple wakeups.

2.4.2.8.3. Wait For Interrupt

RP2040 supports Wait For Interrupt through the hint instruction, WFI.

When a processor issues a WFI instruction it can suspend execution and enter a low-power state. It can remain in that state until the processor detects one of the following WFI wake up events:

• A reset.
• An asynchronous exception at a priority that, if PRIMASK.PM was set to 0, would preempt any currently active exceptions.

Note

If PRIMASK.PM is set to 1, an asynchronous exception that has a higher group priority than any active exception results in a WFI instruction exit. If the group priority of the exception is less than or equal to the execution group priority, the exception is ignored.

• If debug is enabled, a debug event.
• A WFI wakeup event.

The WFI instruction completes when the hardware detects a WFI wake up event.

The processor recognizes WFI wake up events only after issuing the WFI instruction.

2.4.2.8.4. Wakeup Interrupt Controller

The Wakeup Interrupt Controller (WIC) is used to wake the processor from a DEEPSLEEP state as controlled by the SCR register. In a DEEPSLEEP state clocks to the processor core and NVIC are not running. It can take a few cycles to wake from a DEEPSLEEP state.

The WIC takes inputs from the receive event signal (from the other processor), 32 interrupts lines, and NMI.

For more power saving, RP2040 supports system level power saving modes as defined in Section 2.11 which also includes code examples.

2.4.2.9. Reset Control

The Cortex M0+ Reset Control block controls the following resets:

• Debug reset
• M0+ core reset
• PMU reset

After power up, both processors are released from reset (see details in Section 2.13.2). This releases reset to Debug, M0+ core and PMU.

Once running, resets can be triggered from the Debugger, NVIC (using AIRCR.SYSRESETREQ), or the RP2040 Power On State Machine controller (see details in Section 2.13). The NVIC only resets the Cortex-M0+ processor core (not the Debug or PMU), whereas the Power On State Machine controller can reset the processor subsystem which asserts all resets in the subsystem (Debug, M0+ core, PMU).

2.4.3. Programmer’s model

2.4.3.1. About the programmer’s model

The ARMv6-M Architecture Reference Manual provides a complete description of the programmer’s model. This chapter gives an overview of the Cortex-M0+ programmer’s model that describes the implementation-defined options. It also contains the ARMv6-M Thumb instructions it uses and their cycle counts for the processor. Additional details are in following chapters

• Section 2.4.4 summarizes the system control features of the programmer’s model.
• Section 2.4.5 summarizes the NVIC features of the programmer’s model.
• Section 2.3.4 summarizes the Debug features of the programmer’s model.

2.4.3.2. Modes of operation and execution

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

2.4.3.3. Instruction set summary

The processor implements the ARMv6-M Thumb instruction set, including a number of 32-bit instructions that use Thumb-2 technology. The ARMv6-M instruction set comprises:

• All of the 16-bit Thumb instructions from ARMv7-M excluding CBZ, CBNZ and IT.
• The 32-bit Thumb instructions BL, DMB, DSB, ISB, MRS and MSR.

Table 81 shows the Cortex-M0+ instructions and their cycle counts. The cycle counts are based on a system with zero wait-states.
Table 81. Cortex-M0+ instruction summary

Table Notes

a 2 if to AHB interface or SCS, 1 if to single-cycle I/O port.
b N is the number of elements in the list.
c N is the number of elements in the list including PC or LR.
d 2 if taken, 1 if not-taken.
e Cycle count depends on processor and debug configuration.
f Excludes time spent waiting for an interrupt or event.
g Executes as NOP.

See the ARMv6-M Architecture Reference Manual for more information about the ARMv6-M Thumb instructions.

2.4.3.4. Memory model

The processor contains a bus matrix that arbitrates the processor core and Debug Access Port (DAP) memory accesses to both the external memory system and to the internal NVIC and debug components.

Priority is always given to the processor to ensure that any debug accesses are as non-intrusive as possible. For a zero wait-state system, all debug accesses to system memory, NVIC, and debug resources are completely non-intrusive for typical code execution.

The system memory map is ARMv6-M architecture compliant, and is common both to the debugger and processor accesses. Transactions are routed as follows:

• All accesses below 0xd0000000 or above 0xefffffff appear as AHB-Lite transactions on the AHB-Lite master port of the processor.
• Accesses in the range 0xd0000000 to 0xdfffffff are handled by the SIO.
• Accesses in the range 0xe0000000 to 0xefffffff are handled within the processor and do not appear on the AHB-Lite master port of the processor.

The processor supports only word size accesses in the range 0xd0000000 - 0xefffffff.

Table 82 shows the code, data, and device suitability for each region of the default memory map. This is the memory map used by implementations when the MPU is disabled. The attributes and permissions of all regions, except that targeting the Cortex-M0+ NVIC and debug components, can be modified using an implemented MPU.
Table 82. M0+ Default memory map usage

a. Space reserved for Cortex-M0+ NVIC and debug components.

Note

Regions not marked as suitable for code behave as eXecute-Never (XN) and generate a HardFault exception if code attempts to execute from this location.

See the ARMv6-M Architecture Reference Manual for more information about the memory model.

2.4.3.5. Processor core registers summary

Table 83 shows the processor core register set summary. Each of these registers is 32 bits wide.
Table 83. M0+ processor core register set summary

Note

See the ARMv6-M Architecture Reference Manual for information about the processor core registers and their addresses, access types, and reset values.

2.4.3.6. Exceptions

This section describes the exception model of the processor.

2.4.3.6.1. Exception handling

The processor implements advanced exception and interrupt handling, as described in the ARMv6-M Architecture Reference Manual. To minimize interrupt latency, the processor abandons any load-multiple or store-multiple instruction to take any pending interrupt. On return from the interrupt handler, the processor restarts the load-multiple or storemultiple instruction from the beginning.

This means that software must not use load-multiple or store-multiple instructions when a device is accessed in a memory region that is read-sensitive or sensitive to repeated writes. The software must not use these instructions in any case where repeated reads or writes might cause inconsistent results or unwanted side-effects.

The processor implementation can ensure that a fixed number of cycles are required for the NVIC to detect an interrupt signal and the processor fetch the first instruction of the associated interrupt handler. If this is done, the highest priority interrupt is jitter-free. This will depend on where the interrupt handler is located and if another higher priority master is accessing that memory. SRAM4 and SRAM5 are provided that may be allocated to interrupt handlers for each processor so this is jitter-free.

To reduce interrupt latency and jitter, the Cortex-M0+ processor implements both interrupt late-arrival and interrupt tailchaining mechanisms, as defined by the ARMv6-M architecture. The worst case interrupt latency, for the highest priority active interrupt in a zero wait-state system not using jitter suppression, is 15 cycles.

The processor exception model has the following implementation-defined behaviour in addition to the architecture specified behaviour:

• Exceptions on stacking from HardFault to NMI lockup at NMI priority.
• Exceptions on unstacking from NMI to HardFault lockup at HardFault priority.

2.4.4. System control

2.4.4.1. System control register summary

Table 84 gives the system control registers. Each of these registers is 32 bits wide.
Table 84. M0+ System control registers

Note

• All system control registers are only accessible using word transfers. Any attempt to read or write a halfword or byte is Unpredictable.
• See the List of Registers or ARMv6-M Architecture Reference Manual for more information about the system control registers, and their addresses and access types, and reset values.

2.4.4.1.1. CPUID Register

The CPUID contains the part number, version, and implementation information that is specific to the processor.

 IMPORTANT

This standard internal Arm register contains information about the type of processor. It should not be confused with CPUID (Section 2.3.1.1), an RP2040 SIO register which reads as 0 on core 0 and 1 on core 1.

2.4.5. NVIC

2.4.5.1. About the NVIC

External interrupt signals connect to the Nested Vectored Interrupt Controller (NVIC), and the NVIC prioritizes the interrupts. Software can set the priority of each interrupt. The NVIC and the Cortex-M0+ processor core are closely coupled, providing low latency interrupt processing and efficient processing of late arriving interrupts.

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 the vector table. Details of nesting and vectoring behaviour are given in the ARMv6-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.

Processor exception handling is described in Exceptions section.

2.4.5.1.1. SysTick timer

A 24-bit SysTick system timer, extends the functionality of both the processor and the NVIC and provides:

• A 24-bit system timer (SysTick).
• Additional configurable priority SysTick interrupt.

The SysTick timer uses a 1μs pulse as a clock enable. This is generated in the watchdog block as timer_tick. Accuracy of SysTick timing depends upon accuracy of this timer_tick. The SysTick timer can also run from the system clock (see SYST_CALIB).

See the ARMv6-M Architecture Reference Manual for more information.

2.4.5.1.2. Low power modes

The implementation includes a WIC. This enables the processor and NVIC to be put into a very low-power sleep mode leaving the WIC to identify and prioritize interrupts.

The processor fully implements the Wait For Interrupt (WFI), Wait For Event (WFE) and the Send Event (SEV) instructions. In addition, the processor also supports the use of SLEEPONEXIT, that causes the processor core to enter sleep mode when it returns from an exception handler to Thread mode. See the ARMv6-M Architecture Reference Manual for more information.

2.4.5.2. NVIC register summary

Table 85 shows the NVIC registers. Each of these registers is 32 bits wide.
Table 85. M0+ NVIC registers

Note

See the List of Registers or ARMv6-M Architecture Reference Manual for more information about the NVIC registers and their addresses, access types, and reset values.

2.4.6. MPU

2.4.6.1. About the MPU

The MPU is a component for memory protection which allows the processor to support the ARMv6 Protected Memory System Architecture model. The MPU provides full support for:

• Eight unified protection regions.
• Overlapping protection regions, with ascending region priority:
◦ 7 = highest priority.
◦ 0 = lowest priority.
• Access permissions.
• Exporting memory attributes to the system.

MPU mismatches and permission violations invoke the HardFault handler. See the ARMv6-M Architecture Reference Manual for more information.

You can use the MPU to:

• Enforce privilege rules.
• Separate processes.
• Manage memory attributes.

2.4.6.2. MPU register summary

Table 86 shows the MPU registers. Each of these registers is 32 bits wide.
Table 86. M0+ MPU registers

Note

• See the ARMv6-M Architecture Reference Manual for more information about the MPU registers and their addresses, access types, and reset values.
• The MPU supports region sizes from 256-bytes to 4Gb, with 8-sub regions per region.

2.4.7. Debug

Basic debug functionality includes processor halt, single-step, processor core register access, Reset and HardFault Vector Catch, unlimited software breakpoints, and full system memory access. See the ARMv6-M Architecture Reference Manual.

The debug features for this device are:

• A breakpoint unit supporting 4 hardware breakpoints.

• A watchpoint unit supporting 2 watchpoints.

2.4.8. List of Registers

The ARM Cortex-M0+ registers start at a base address of 0xe0000000 (defined as PPB_BASE in SDK).

Table 87. List of M0PLUS registers

M0PLUS: SYST_CSR Register

Offset: 0xe010

Description

Use the SysTick Control and Status Register to enable the SysTick features.

Table 88. SYST_CSR Register

M0PLUS: SYST_RVR Register

Offset: 0xe014

Description

Use the SysTick Reload Value Register to specify the start value to load into the current value register when the counter reaches 0. It can be any value between 0 and 0x00FFFFFF. A start value of 0 is possible, but has no effect because the SysTick interrupt and COUNTFLAG are activated when counting from 1 to 0. The reset value of this register is UNKNOWN.

To generate a multi-shot timer with a period of N processor clock cycles, use a RELOAD value of N-1. For example, if the SysTick interrupt is required every 100 clock pulses, set RELOAD to 99.

Table 89. SYST_RVR Register

M0PLUS: SYST_CVR Register

Offset: 0xe018

Description

Use the SysTick Current Value Register to find the current value in the register. The reset value of this register is UNKNOWN.

Table 90. SYST_CVR Register

M0PLUS: SYST_CALIB Register

Offset: 0xe01c

Description

Use the SysTick Calibration Value Register to enable software to scale to any required speed using divide and multiply.

Table 91. SYST_CALIB Register

M0PLUS: NVIC_ISER Register

Offset: 0xe100

Description

Use the Interrupt Set-Enable Register to enable interrupts and determine which interrupts are currently enabled.

If a pending interrupt is enabled, the NVIC activates the interrupt based on its priority. If an interrupt is not enabled, asserting its interrupt signal changes the interrupt state to pending, but the NVIC never activates the interrupt, regardless of its priority.

Table 92. NVIC_ISER Register

M0PLUS: NVIC_ICER Register

Offset: 0xe180

Description

Use the Interrupt Clear-Enable Registers to disable interrupts and determine which interrupts are currently enabled.

Table 93. NVIC_ICER Register

M0PLUS: NVIC_ISPR Register

Offset: 0xe200

Description

The NVIC_ISPR forces interrupts into the pending state, and shows which interrupts are pending.

Table 94. NVIC_ISPR Register

M0PLUS: NVIC_ICPR Register

Offset: 0xe280

Description

Use the Interrupt Clear-Pending Register to clear pending interrupts and determine which interrupts are currently pending.

Table 95. NVIC_ICPR Register

M0PLUS: NVIC_IPR0 Register

Offset: 0xe400

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Note: Writing 1 to an NVIC_ICPR bit does not affect the active state of the corresponding interrupt.

These registers are only word-accessible

Table 96. NVIC_IPR0 Register

M0PLUS: NVIC_IPR1 Register

Offset: 0xe404

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Table 97. NVIC_IPR1 Register

M0PLUS: NVIC_IPR2 Register

Offset: 0xe408

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Table 98. NVIC_IPR2 Register

M0PLUS: NVIC_IPR3 Register

Offset: 0xe40c

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Table 99. NVIC_IPR3 Register

M0PLUS: NVIC_IPR4 Register

Offset: 0xe410

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Table 100. NVIC_IPR4 Register

M0PLUS: NVIC_IPR5 Register

Offset: 0xe414

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Table 101. NVIC_IPR5 Register

M0PLUS: NVIC_IPR6 Register

Offset: 0xe418

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Table 102. NVIC_IPR6 Register

M0PLUS: NVIC_IPR7 Register

Offset: 0xe41c

Description

Use the Interrupt Priority Registers to assign a priority from 0 to 3 to each of the available interrupts. 0 is the highest priority, and 3 is the lowest.

Table 103. NVIC_IPR7 Register

M0PLUS: CPUID Register

Offset: 0xed00

Description

Read the CPU ID Base Register to determine: the ID number of the processor core, the version number of the processor core, the implementation details of the processor core.

Table 104. CPUID Register

M0PLUS: ICSR Register

Offset: 0xed04

Description

Use the Interrupt Control State Register to set a pending Non-Maskable Interrupt (NMI), set or clear a pending PendSV, set or clear a pending SysTick, check for pending exceptions, check the vector number of the highest priority pended exception, check the vector number of the active exception.

Table 105. ICSR Register

M0PLUS: VTOR Register

Offset: 0xed08

Description

The VTOR holds the vector table offset address.

Table 106. VTOR Register

M0PLUS: AIRCR Register

Offset: 0xed0c

Description

Use the Application Interrupt and Reset Control Register to: determine data endianness, clear all active state information from debug halt mode, request a system reset.

Table 107. AIRCR Register

M0PLUS: SCR Register

Offset: 0xed10

Description

System Control Register. Use the System Control Register for power-management functions: signal to the system when the processor can enter a low power state, control how the processor enters and exits low power states.

Table 108. SCR Register

M0PLUS: CCR Register

Offset: 0xed14

Description

The Configuration and Control Register permanently enables stack alignment and causes unaligned accesses to result in a Hard Fault.

Table 109. CCR Register

M0PLUS: SHPR2 Register

Offset: 0xed1c

Description

System handlers are a special class of exception handler that can have their priority set to any of the priority levels.

Use the System Handler Priority Register 2 to set the priority of SVCall.

Table 110. SHPR2 Register

M0PLUS: SHPR3 Register

Offset: 0xed20

Description

System handlers are a special class of exception handler that can have their priority set to any of the priority levels. Use the System Handler Priority Register 3 to set the priority of PendSV and SysTick.

Table 111. SHPR3 Register

M0PLUS: SHCSR Register

Offset: 0xed24

Description

Use the System Handler Control and State Register to determine or clear the pending status of SVCall.

Table 112. SHCSR Register

M0PLUS: MPU_TYPE Register

Offset: 0xed90

Description

Read the MPU Type Register to determine if the processor implements an MPU, and how many regions the MPU supports.

Table 113. MPU_TYPE Register

M0PLUS: MPU_CTRL Register

Offset: 0xed94

Description

Use the MPU Control Register to enable and disable the MPU, and to control whether the default memory map is enabled as a background region for privileged accesses, and whether the MPU is enabled for HardFaults and NMIs.

Table 114. MPU_CTRL Register

M0PLUS: MPU_RNR Register

Offset: 0xed98

Description

Use the MPU Region Number Register to select the region currently accessed by MPU_RBAR and MPU_RASR.

Table 115. MPU_RNR Register

M0PLUS: MPU_RBAR Register

Offset: 0xed9c

Description

Read the MPU Region Base Address Register to determine the base address of the region identified by MPU_RNR. Write to update the base address of said region or that of a specified region, with whose number MPU_RNR will also be updated.

Table 116. MPU_RBAR Register

M0PLUS: MPU_RASR Register

Offset: 0xeda0

Description

Use the MPU Region Attribute and Size Register to define the size, access behaviour and memory type of the region identified by MPU_RNR, and enable that region.

Table 117. MPU_RASR Register

2.5. DMA

The RP2040 Direct Memory Access (DMA) controller has separate read and write master connections to the bus fabric, and performs bulk data transfers on a processor’s behalf. This leaves processors free to attend to other tasks, or enter low-power sleep states. The data throughput of the DMA is also significantly higher than one of RP2040’s processors.

Figure 12. DMA Architecture Overview. The read master can read data from some address every clock cycle. Likewise, the write master can write to another address. The address generator produces matched pairs of read and write addresses, which the masters consume through the address FIFOs. Up to 12 transfer sequences may be in progress simultaneously, supervised by software via the control and status registers.

graph TD
    A["From System"] --> B["AHB-lite Read Master"]
    B --> C["Transfer Data FIFO"]
    C --> D["AHB-lite Write Master"]
    D --> E["Write Address FIFO"]
    E --> F["Address Generator"]
    F --> G["Read Address FIFO"]
    G --> B
    F --> H["Control/Status Registers"]
    H --> I["AHB-lite Slave Interface"]
    I --> H

The DMA can perform one read access and one write access, up to 32 bits in size, every clock cycle. There are 12 independent channels, each which supervise a sequence of bus transfers, usually in one of the following scenarios:

• Memory-to-peripheral: a peripheral signals the DMA when it needs more data to transmit. The DMA reads data from an array in RAM or flash, and writes to the peripheral’s data FIFO.
• Peripheral-to-memory: a peripheral signals the DMA when it has received data. The DMA reads this data from the peripheral’s data FIFO, and writes it to an array in RAM.
• Memory-to-memory: the DMA transfers data between two buffers in RAM, as fast as possible.

Each channel has its own control and status registers (CSRs), with which software can program and monitor the channel’s progress. When multiple channels are active at the same time, the DMA shares bandwidth evenly between the channels, with round-robin over all channels which are currently requesting data transfers.

The transfer size can be either 32, 16, or 8 bits. This is configured once per channel: source transfer size and destination transfer size are the same. The DMA performs standard byte lane replication on narrow writes, so byte data is available in all 4 bytes of the databus, and halfword data in both halfwords.

Channels can be combined in varied ways for more sophisticated behaviour and greater autonomy. For example, one channel can configure another, loading configuration data from a sequence of control blocks in memory, and the second can then call back to the first via the CHAIN_TO option, when it needs to be reconfigured.

Making the DMA more autonomous means that much less processor supervision is required: overall this allows the system to do more at once, or to dissipate less power.

2.5.1. Configuring Channels

Each channel has four control/status registers:

• READ_ADDR is a pointer to the next address to be read from
• WRITE_ADDR is a pointer to the next address to be written to
• TRANS_COUNT shows the number of transfers remaining in the current transfer sequence, and is used to program the number of transfers in the next transfer sequence (see Section 2.5.1.2).
• CTRL is used to configure all other aspects of the channel’s behaviour, to enable/disable it, and to check for completion.

These are live registers: they update continuously as the channel progresses.

2.5.1.1. Read and Write Addresses

READ_ADDR and WRITE_ADDR contain the address the channel will next read from, and write to, respectively. These registers update automatically after each read/write access. They increment by 1, 2 or 4 bytes at a time, depending on the transfer size configured in CTRL.

Software should generally program these registers with new start addresses each time a new transfer sequence starts. If READ_ADDR and WRITE_ADDR are not reprogrammed, the DMA will use the current values as start addresses for the next transfer. For example:

• If the address does not increment (e.g. it is the address of a peripheral FIFO), and the next transfer sequence is to/from that same address, there is no need to write to the register again.
• When transferring to/from a consecutive series of buffers in memory (e.g. scattering and gathering), an address register will already have incremented to the start of the next buffer at the completion of a transfer.

By not programming all four CSRs for each transfer sequence, software can use shorter interrupt handlers, and more compact control block formats when used with channel chaining (see register aliases in Section 2.5.2.1, chaining in Section 2.5.2.2).

 CAUTION

READ_ADDR and WRITE_ADDR must always be aligned to the current transfer size, as specified in CTRL.DATA_SIZE. It is up to software to ensure the initial values are correctly aligned.

2.5.1.2. Transfer Count

Reading from TRANS_COUNT yields the number of transfers remaining in the current transfer sequence. This value updates continuously as the channel progresses. Writing to TRANS_COUNT sets the length of the next transfer sequence. Up to 232-1 transfers can be performed in one sequence.

Each time the channel starts a new transfer sequence, the most recent value written to TRANS_COUNT is copied to the live transfer counter, which will then start to decrement again as the new transfer sequence makes progress. For debugging purposes, the last value written can be read from the DBG_TCR (TRANS_COUNT reload value) register.

If the channel is triggered multiple times without intervening writes to TRANS_COUNT, it performs the same number of transfers each time. For example, when chained to, one channel might load a fixed-size control block into another channel’s CSRs. TRANS_COUNT would be programmed once by software, and then reload automatically every time.

Alternatively, TRANS_COUNT can be written with a new value before starting each transfer sequence. If TRANS_COUNT is the channel trigger (see Section 2.5.2.1), the channel will start immediately, and the value just written will be used, not the value currently in the reload register.

 NOTE

The TRANS_COUNT is the number of transfers to be performed. The total number of bytes transferred is TRANS_COUNT times the size of each transfer in bytes, given by CTRL.DATA_SIZE.

2.5.1.3. Control/Status

The CTRL register has more, smaller fields than the other 3 registers, and full details of these are given in the CTRL register listings. Among other things, CTRL is used to:

• Configure the size of this channel’s data transfers, via CTRL.DATA_SIZE. Reads and writes are the same size.
• Configure if and how READ_ADDR and WRITE_ADDR increment after each read or write, via CTRL.INCR_WRITE, CTRL.INCR_READ, CTRL.RING_SEL, CTRL.RING_SIZE. Ring transfers are available, where one of the address pointers wraps at some powerof-2 boundary.

• Select another channel (or none) to be triggered when this channel completes, via CTRL.CHAIN_TO.
• Select a peripheral data request (DREQ) signal to pace this channel’s transfers, via CTRL.TREQ_SEL.
• See when the channel is idle, via CTRL.BUSY.
• See if the channel has encountered a bus error, e.g. due to a faulty address being accessed, via CTRL.AHB_ERROR, CTRL.READ_ERROR, or CTRL.WRITE_ERROR.

2.5.2. Starting Channels

There are three ways to start a channel:

• Writing to a channel trigger register
• A chain trigger from another channel which has just completed, and has its CHAIN_TO field configured
• The MULTI_CHAN_TRIGGER register, which can start multiple channels at once

Each of these covers different use cases. For example, trigger registers are simple and efficient when configuring and starting a channel in an interrupt service routine, and CHAIN_TO allows one channel to callback to another channel, which can then reconfigure the first channel.

NOTE

Triggering a channel which is already running has no effect.

2.5.2.1. Aliases and Triggers

Table 118. Control register aliases. Each channel has four control/status registers. Each register can be accessed at multiple different addresses. In each naturally-aligned group of four, all four registers appear, in different orders.

The four CSRs are aliased multiple times in memory. Each alias — of which there are four — exposes the same four physical registers, but in a different order. The final register in each alias (at offset +0xC, highlighted) is a trigger register. Writing to the trigger register starts the channel.

Often, only alias 0 is used, and aliases 1-3 can be ignored. The channel is configured and started by writing READ_ADDR, WRITE_ADDR, TRANS_COUNT and finally CTRL. Since CTRL is the trigger register in alias 0, this starts the channel.

The other aliases allow more compact control block lists when using one channel to configure another, and more efficient reconfiguration and launch in interrupt handlers:

• Each CSR is a trigger register in one of the aliases:

◦ When gathering fixed-size buffers into a peripheral, the DMA channel can be configured and launched by writing only READ_ADDR_TRIG.
◦ When scattering from a peripheral to fixed-size buffers, the channel can be configured and launched by writing only WRITE_ADDR_TRIG.

• Useful combinations of registers appear as naturally-aligned tuples which contain a trigger register. In conjunction with channel chaining and address wrapping, these implement compressed control block formats, e.g.:

◦ (WRITE_ADDR, TRANS_COUNT_TRIG) for peripheral scatter operations

◦ (TRANS_COUNT, READ_ADDR_TRIG) for peripheral gather operations, or calculating CRCs on a list of buffers
◦ (READ_ADDR, WRITE_ADDR_TRIG) for manipulating fixed-size buffers in memory

Trigger registers do not start the channel if:

• The channel is disabled via CTRL.EN. (If the trigger is CTRL, the just-written value of EN is used, not the value currently in the CTRL register.)
• The channel is already running
• The value 0 is written to the trigger register. (This is useful for ending control block chains. See null triggers, Section 2.5.2.3)

2.5.2.2. Chaining

When a channel completes, it can name a different channel to immediately be triggered. This can be used as a callback for the second channel to reconfigure and restart the first.

This feature is configured through the CHAIN_TO field in the channel CTRL register. This 4-bit value selects a channel that will start when this one finishes. A channel can not chain to itself. Setting CHAIN_TO to a channel’s own index means no chaining will take place.

Chain triggers behave the same as triggers from other sources, such as trigger registers. For example, they cause TRANS_COUNT to reload, and they are ignored if the targeted channel is already running.

One application for CHAIN_TO is for a channel to request reconfiguration by another channel, from a sequence of control blocks in memory. Channel A is configured to perform a wrapped transfer from memory to channel B’s control registers (including a trigger register), and channel B is configured to chain back to channel A when it completes each transfer sequence. This is shown more explicitly in the DMA control blocks example (Section 2.5.6.2).

Use of the register aliases (Section 2.5.2.1) enables compact formats for DMA control blocks: as little as one word in some cases.

Another use of chaining is a "ping-pong" configuration, where two channels each trigger one another. The processor can respond to the channel completion interrupts, and reconfigure each channel after it completes; however, the chained channel, which has already been configured, starts immediately. In other words, channel configuration and channel operation are pipelined. Performance can improve dramatically where many short transfer sequences are required.

The Section 2.5.6 goes into more detail on the possibilities of chain triggers, in the real world.

2.5.2.3. Null Triggers and Chain Interrupts

As mentioned in Section 2.5.2.1, writing all-zeroes to a trigger register does not start the channel. This is called a null trigger, and it has two purposes:

• Cause a halt at the end of an array of control blocks, by appending an all-zeroes block
• Reduce the number of interrupts generated when control blocks are used

By default, a channel will generate an interrupt each time it finishes a transfer sequence, unless that channel’s IRQ is masked in INTE0 or INTE1. The rate of interrupts can be excessive, particularly as processor attention is generally not required while a sequence of control blocks are in progress; however, processor attention is required at the end of a chain.

The channel CTRL register has a field called IRQ_QUIET. Its default value is 0. When this set to 1, channels generate an interrupt when they receive a null trigger, and at no other time. The interrupt is generated by the channel which receives the trigger.

2.5.3. Data Request (DREQ)

Peripherals produce or consume data at their own pace. If the DMA simply transferred data as fast as possible, loss or corruption of data would ensue. DREQs are a communication channel between peripherals and the DMA, which enables the DMA to pace transfers according to the needs of the peripheral.

The CTRL.TREQ_SEL (transfer request) field selects an external DREQ. It can also be used to select one of the internal pacing timers, or select no TREQ at all (the transfer proceeds as fast as possible), e.g. for memory-to-memory transfers.

2.5.3.1. System DREQ Table

There is a global assignment of DREQ numbers to peripheral DREQ channels.

Table 119. DREQs

2.5.3.2. Credit-based DREQ Scheme

The RP2040 DMA is designed for systems where:

• The area and power cost of large peripheral data FIFOs is prohibitive
• The bandwidth demands of individual peripherals may be high, e.g. >50% bus injection rate for short periods
• Bus latency is low, but multiple masters may be competing for bus access

In addition, the DMA’s transfer FIFOs and dual-master structure permit multiple accesses to the same peripheral to be in flight at once, to improve gross throughput. Choice of DREQ mechanism is therefore critical:

• The traditional "turn on the tap" method can cause overflow if multiple writes are backed up in the TDF. Some systems solve this by overprovisioning peripheral FIFOs and setting the DREQ threshold below the full level, but this wastes precious area and power
• The ARM-style single and burst handshake does not permit additional requests to be registered while the current request is being served. This limits performance when FIFOs are very shallow.

The RP2040 DMA uses a credit-based DREQ mechanism. For each peripheral, the DMA attempts to keep as many transfers in flight as the peripheral has capacity for. This enables full bus throughput (1 word per clock) through an 8- deep peripheral FIFO with no possibility of overflow or underflow, in the absence of fabric latency or contention.

For each channel, the DMA maintains a counter. Each 1-clock pulse on the dreq signal will increment this counter (saturating). When nonzero, the channel requests a transfer from the DMA’s internal arbiter, and the counter is decremented when the transfer is issued to the address FIFOs. At this point the transfer is in flight, but has not yet necessarily completed.

Figure 13. DREQ counting

The effect is to upper bound the number of in-flight transfers based on the amount of room or data available in the peripheral FIFO. In the steady state, this gives maximum throughput, but can’t underflow or underflow.

One caveat is that the user must not access a FIFO which is currently being serviced by the DMA. This causes the channel and peripheral to become desynchronised, and can cause corruption or loss of data.

Another caveat is that multiple channels should not be connected to the same DREQ.

2.5.4. Interrupts

Each channel can generate interrupts; these can be masked on a per-channel basis using the INTE0 or INTE1 registers. There are two circumstances where a channel raises an interrupt request:

• On the completion of each transfer sequence, if CTRL.IRQ_QUIET is disabled
• On receiving a null trigger, if CTRL.IRQ_QUIET is enabled

The masked interrupt status is visible in the INTS registers; there is one bit for each channel. Interrupts are cleared by writing a bit mask to INTS. One idiom for acknowledging interrupts is to read INTS and then write the same value back, so only enabled interrupts are cleared.

The RP2040 DMA provides two system IRQs, with independent masking and status registers (e.g. INTE0, INTE1). Any combination of channel interrupt requests can be routed to either system IRQ. For example:

• Some channels can be given a higher priority in the system interrupt controller, if they have particularly tight timing requirements
• In multiprocessor systems, different channel interrupts can be routed independently to different cores

For debugging purposes, the INTF registers can force either IRQ to be asserted.

2.5.5. Additional Features

2.5.5.1. Pacing Timers

These allow transfer of data roughly once every n clk_sys clocks instead of using external peripheral DREQ to trigger transfers. A fractional (X/Y) divider is used, and will generate a maximum of 1 request per clk_sys cycle.

There are 4 timers available in RP2040. Each DMA is able to select any of these in CTRL.TREQ_SEL.

2.5.5.2. CRC Calculation

The DMA can watch data from a given channel passing through the data FIFO, and calculate checksums based on this data. This a purely passive affair: the data is not altered by this hardware, only observed.

The feature is controlled via the SNIFF_CTRL and SNIFF_DATA registers, and can be enabled/disabled per DMA transfer via the CTRL.SNIFF_EN field.

As this hardware cannot place backpressure on the FIFO, it must keep up with the DMA’s maximum transfer rate of 32 bits per clock.

The supported checksums are:

• CRC-32, MSB-first and LSB-first
• CRC-16-CCITT, MSB-first and LSB-first
• Simple summation (add to 32-bit accumulator)
• Even parity

The result register is both readable and writable, so that the initial seed value can be set.

Bit/byte manipulations are available on the result which may aid specific use cases:

• Bit inversion
• Bit reversal
• Byte swap

These manipulations do not affect the CRC calculation, just how the data is presented in the result register.

2.5.5.3. Channel Abort

It is possible for a channel to get into an irrecoverable state: e.g. if commanded to transfer more data than a peripheral will ever request, it will never complete. Clearing the CTRL.EN bit merely pauses the channel, and does not solve the problem. This should not occur under normal circumstances, but it is important that there is a mechanism to recover without simply hard-resetting the entire DMA block.

The CHAN_ABORT register forces channels to complete early. There is one bit for each channel, and writing a 1 terminates that channel. This clears the transfer counter and forces the channel into an inactive state.

CAUTION

Due to RP2040-E13, aborting a DMA channel that is making progress (i.e. not stalled on an inactive DREQ) may cause a completion IRQ to assert. The channel interrupt enable should be cleared before performing the abort, and the interrupt should be checked and cleared after the abort.

At the time an abort is triggered, a channel may have bus transfers currently in flight between the read and write master, and these transfers cannot be revoked. The CTRL.BUSY flag stays high until these transfers complete, and the channel reaches a safe state, which generally takes only a few cycles. The channel must not be restarted until its CTRL.BUSY flag deasserts. Starting a new sequence of transfers whilst transfers from an old sequence are still in flight can lead to unpredictable behaviour.

2.5.5.4. Debug

Debug registers are available for each DMA channel to show the dreq counter DBG_CTDREQ and next transfer count DBG_TCR. These can also be used to reset a DMA channel if required.

2.5.6. Example Use Cases

2.5.6.1. Using Interrupts to Reconfigure a Channel

When a channel finishes a block of transfers, it becomes available for making more transfers. Software detects that the channel is no longer busy, and reconfigures and restarts the channel. One approach is to poll the CTRL_BUSY bit until the channel is done, but this loses one of the key advantages of the DMA, namely that it does not have to operate in lockstep with a processor. By setting the correct bit in INTE0 or INTE1, we can instruct the DMA to raise one of its two interrupt request lines when a given channel completes. Rather than repeatedly asking if a channel is done, we are told.

NOTE

Having two system interrupt lines allows different channel completion interrupts to be routed to different cores, or to preempt one another on the same core if one channel is more time-critical.

When the interrupt is asserted, the processor can be configured to drop whatever it is doing and call a user-specified handler function. The handler can reconfigure and restart the channel. When the handler exits, the processor returns to the interrupted code running in the foreground.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/dma/channel\_irq/channel\_irq.c Lines 35 - 52

void dma_handler() {
    static int pwm_level = 0;
    static uint32_t wavetable[N_PWM_LEVELS];
    static bool first_run = true;
    // Entry number `i` has `i` one bits and '(32 - i)` zero bits.
    if (first_run) {
    first_run = false;
    for (int i = 0; i < N_PWM_LEVELS; ++i)
    wavetable[i] = ~(~0u << i);
    }
    // Clear the interrupt request.
    dma_hw->ints0 = 1u << dma_chan;
    // Give the channel a new wave table entry to read from, and re-trigger it
    dma_channel_set_read_addr(dma_chan, &wavetable[pwm_level], true);
    pwm_level = (pwm_level + 1) % N_PWM_LEVELS;
} 

In many cases, most of the configuration can be done the first time the channel is started, and only addresses and transfer lengths need reprogramming in the DMA handler.

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/dma/channel\_irq/channel\_irq.c Lines 54 - 94

int main() {
    #ifndef PICO_DEFAULT_LED_PIN
    #warning dma/channel_irq example requires a board with a regular LED
    #else
    // Set up a PIO state machine to serialise our bits
    uint offset = pio_add_program(pio0, &pio_serialiser_program);
    pio_serialiser_program_init(pio0, 0, offset, PICO_DEFAULT_LED_PIN, PIO_SERIAL_CLKDIV);
    // Configure a channel to write the same word (32 bits) repeatedly to PIO0
    // SM0's TX FIFO, paced by the data request signal from that peripheral.
    dma_chan = dma_claim_unused_channel(true);
    dma_channel_config c = dma_channel_get_default_config(dma_chan);
    channel_config_set_transfer_data_size(&c, DMA_SIZE_32);
    channel_config_set_read_increment(&c, false);
    channel_config_set_dreq(&c, DREQ_PIO0_TX0);

    dma_channel_configure(
    dma_chan,
    &c,
    &pio0_hw->txf[0], // Write address (only need to set this once)
    NULL, // Don't provide a read address yet
    PWM_REPEAT_COUNT, // Write the same value many times, then halt and interrupt
    false // Don't start yet
); 

// Tell the DMA to raise IRQ line 0 when the channel finishes a block
dma_channel_set_irq0_enabled(dma_chan, true);

// Configure the processor to run dma_handler() when DMA IRQ 0 is asserted
irq_set_exclusive_handler(DMA_IRQ_0, dma_handler);
irq_set_enabled(DMA_IRQ_0, true);

// Manually call the handler once, to trigger the first transfer
dma_handler();

// Everything else from this point is interrupt-driven. The processor has
// time to sit and think about its early retirement -- maybe open a bakery?
while (true)
tight_loop_contents();

#endif
} 

One disadvantage of this technique is that we don’t start to reconfigure the channel until some time after the channel makes its last transfer. If there is heavy interrupt activity on the processor, this may be quite a long time, and therefore quite a large gap in transfers, which is problematic if we need to sustain a high data throughput.

This is solved by using two channels, with their CHAIN_TO fields crossed over, so that channel A triggers channel B when it completes, and vice versa. At any point in time, one of the channels is transferring data, and the other is either already configured to start the next transfer immediately when the current one finishes, or it is in the process of being reconfigured. When channel A completes, it immediately starts the cued-up transfer on channel B. At the same time, the interrupt is fired, and the handler reconfigures channel A so that it is ready for when channel B completes.

2.5.6.2. DMA Control Blocks

Frequently, multiple smaller buffers must be gathered together and sent to the same peripheral. To address this use case, the RP2040 DMA can execute a long and complex sequence of transfers without processor control. One channel repeatedly reconfigures a second channel, and the second channel restarts the first each time it completes block of transfers.

Because the first DMA channel is transferring data directly from memory to the second channel’s control registers, the format of the control blocks in memory must match those registers. The last register written to, each time, will be one of the trigger registers (Section 2.5.2.1) which will start the second channel on its programmed block of transfers. The register aliases (Section 2.5.2.1) give some flexibility for the block layout, and more importantly allow some registers to be omitted from the blocks, so they occupy less memory and can be loaded more quickly.

This example shows how multiple buffers can be gathered and transferred to the UART, by reprogramming TRANS_COUNT and READ_ADDR_TRIG:

Pico Examples: https://github.com/raspberrypi/pico-examples/blob/master/dma/control\_blocks/control\_blocks.c

/**
 * Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */
// Use two DMA channels to make a programmed sequence of data transfers to the
// UART (a data gather operation). One channel is responsible for transferring
// the actual data, the other repeatedly reprograms that channel.
#include <stdio.h>
#include "pico/stdlib.h"
#include "hardware/dma.h"
#include "hardware/structs/uart.h" 

// These buffers will be DMA'd to the UART, one after the other.
const char word0[] = "Transferring ";
const char word1[] = "one ";
const char word2[] = "word ";
const char word3[] = "at ";
const char word4[] = "a ";
const char word5[] = "time.\n";

// Note the order of the fields here: it's important that the length is before
// the read address, because the control channel is going to write to the last
// two registers in alias 3 on the data channel:
// +0x0 +0x4 +0x8 +0xC (Trigger)
// Alias 0: READ_ADDR WRITE_ADDR TRANS_COUNT CTRL
// Alias 1: CTRL READ_ADDR WRITE_ADDR TRANS_COUNT
// Alias 2: CTRL TRANS_COUNT READ_ADDR WRITE_ADDR
// Alias 3: CTRL WRITE_ADDR TRANS_COUNT READ_ADDR

// This will program the transfer count and read address of the data channel,
// and trigger it. Once the data channel completes, it will restart the
// control channel (via CHAIN_TO) to load the next two words into its control
// registers.

const struct {uint32_t len; const char *data;} control_blocks[] = {
{count_of(word0) - 1, word0}, // Skip null terminator
{count_of(word1) - 1, word1},
{count_of(word2) - 1, word2},
{count_of(word3) - 1, word3},
{count_of(word4) - 1, word4},
{count_of(word5) - 1, word5},
{0, NULL} // Null trigger to end chain.
};

int main() {
#ifndef uart_default
#warning dma/control_blocks example requires a UART
#else
stdio_init_all();
puts("DMA control block example:");
// ctrl_chan loads control blocks into data_chan, which executes them.
int ctrl_chan = dma_claim_unused_channel(true);
int data_chan = dma_claim_unused_channel(true);

// The control channel transfers two words into the data channel's control
// registers, then halts. The write address wraps on a two-word
// (eight-byte) boundary, so that the control channel writes the same two
// registers when it is next triggered.

dma_channel_config c = dma_channel_get_default_config(ctrl_chan);
channel_config_set_transfer_data_size(&c, DMA_SIZE_32);
channel_config_set_read_increment(&c, true);
channel_config_set_write_increment(&c, true);
channel_config_set_ring(&c, true, 3); // 1 << 3 byte boundary on write ptr

dma_channel_configure(
    ctrl_chan,
    &c,
    &dma_hw->ch[data_chan].al3_transfer_count, // Initial write address
    &control_blocks[0], // Initial read address
    2, // Halt after each control block
    false // Don't start yet
); 

// The data channel is set up to write to the UART FIFO (paced by the
// UART's TX data request signal) and then chain to the control channel
// once it completes. The control channel programs a new read address and
// data length, and retriggers the data channel.

c = dma_channel_get_default_config(data_chan);
channel_config_set_transfer_data_size(&c, DMA_SIZE_8);
channel_config_set_dreq(&c, uart_get_dreq(uart_default, true));
// Trigger ctrl_chan when data_chan completes
channel_config_set_chain_to(&c, ctrl_chan);
// Raise the IRQ flag when 0 is written to a trigger register (end of chain):
channel_config_set_irq_quiet(&c, true);

dma_channel_configure(
    data_chan,
    &c,
    &uart_get_hw(uart_default)->dr,
    NULL, // Initial read address and transfer count are unimportant;
    0, // the control channel will reprogram them each time.
    false // Don't start yet.

);
// Everything is ready to go. Tell the control channel to load the first
// control block. Everything is automatic from here.
dma_start_channel_mask(1u << ctrl_chan);

// The data channel will assert its IRQ flag when it gets a null trigger,
// indicating the end of the control block list. We're just going to wait
// for the IRQ flag instead of setting up an interrupt handler.
while (!(dma_hw->intr & 1u << data_chan))
    tight_loop_contents();
dma_hw->ints0 = 1u << data_chan;

puts("DMA finished.");
#endif 

2.5.7. List of Registers

The DMA registers start at a base address of 0x50000000 (defined as DMA_BASE in SDK).

Table 120. List of DMA registers

DMA: CH0_READ_ADDR, CH1_READ_ADDR, …, CH10_READ_ADDR, CH11_READ_ADDR Registers

Offsets: 0x000, 0x040, …, 0x280, 0x2c0

Description

DMA Channel N Read Address pointer

Table 121.

CH0_READ_ADDR,

CH1_READ_ADDR, …,

CH10_READ_ADDR,

CH11_READ_ADDR

Registers

DMA: CH0_WRITE_ADDR, CH1_WRITE_ADDR, …, CH10_WRITE_ADDR, CH11_WRITE_ADDR Registers

Offsets: 0x004, 0x044, …, 0x284, 0x2c4

Description

DMA Channel N Write Address pointer

Table 122.

CH0_WRITE_ADDR,

CH1_WRITE_ADDR, …,

CH10_WRITE_ADDR,

CH11_WRITE_ADDR

Registers

DMA: CH0_TRANS_COUNT, CH1_TRANS_COUNT, …, CH10_TRANS_COUNT, CH11_TRANS_COUNT Registers

Offsets: 0x008, 0x048, …, 0x288, 0x2c8

Description

DMA Channel N Transfer Count

Table 123.

CH0_TRANS_COUNT,

CH1_TRANS_COUNT,

…,

CH10_TRANS_COUNT,

CH11_TRANS_COUNT

Registers

DMA: CH0_CTRL_TRIG, CH1_CTRL_TRIG, …, CH10_CTRL_TRIG, CH11_CTRL_TRIG Registers

Offsets: 0x00c, 0x04c, …, 0x28c, 0x2cc

Description

DMA Channel N Control and Status

Table 124. CH0_CTRL_TRIG, CH1_CTRL_TRIG, …, CH10_CTRL_TRIG, CH11_CTRL_TRIG Registers