5. Electrical and Mechanical

Physical and electrical details of the RP2040 chip.

5.1. Package

Figure 166. Top down view (left, top) and side view (right, top), along with bottom view (left, bottom) of the RP2040 QFN-56 package

Figure 166: Mechanical drawings of the RP2040 QFN-56 package. The top-left drawing is a top-down view showing dimensions A, D, E, B, and a laser mark for pin 1. The top-right drawing is a side view showing dimensions A, A1, A2, A3, and the seating plane. The bottom-left drawing is a bottom view showing dimensions D2, D, E2, L, b, e, and various pad dimensions. The bottom-right table provides tolerance data for various symbols in millimeters and inches.

Figure 166 shows the mechanical details of the RP2040 QFN-56 package. The top-left drawing is a top-down view showing dimensions A, D, E, B, and a laser mark for pin 1. The top-right drawing is a side view showing dimensions A, A1, A2, A3, and the seating plane. The bottom-left drawing is a bottom view showing dimensions D2, D, E2, L, b, e, and various pad dimensions. The bottom-right table provides tolerance data for various symbols in millimeters and inches.

SymbolMillimetreInch
Min.Nom.Max.Min.Nom.Max.
A--0.900--0.035
A10.000-0.0500.000-0.002
A2-0.6500.700-0.0260.028
A30.203 REF0.008 REF
b0.1300.1800.2300.0050.0070.009
D7 BSC0.276 BSC
D23.003.1003.2000.1180.1220.126
E7 BSC0.276 BSC
E23.003.1003.2000.1180.1220.126
L0.3000.4000.5000.0120.0160.020
e0.400 BSC0.016 BSC
R0.065--0.003--
Tolerances of form and position
aaa0.1000.004
bbb0.0700.003
ccc0.1000.004
ddd0.0500.002
eee0.0800.003
fff0.1000.004
Figure 166: Mechanical drawings of the RP2040 QFN-56 package. The top-left drawing is a top-down view showing dimensions A, D, E, B, and a laser mark for pin 1. The top-right drawing is a side view showing dimensions A, A1, A2, A3, and the seating plane. The bottom-left drawing is a bottom view showing dimensions D2, D, E2, L, b, e, and various pad dimensions. The bottom-right table provides tolerance data for various symbols in millimeters and inches.

NOTE

There is no standard size for the central GND pad (or ePad) with QFNs. However, the one on RP2040 is smaller than most. This means that standard 0.4mm QFN-56 footprints provided with CAD tools may need adjusting. This gives the opportunity to route between the central pad and the ones on the periphery, which can help with maintaining power and ground integrity on cheaper PCBs. See Minimal Design Example for an example.

NOTE

Leads have a matte Tin (Sn) finish. Annealing is done post-plating, baking at 150°C for 1 hour. Minimum thickness for lead plating is 8 micromns, and the intermediate layer material is CuFe2P (roughened Copper (Cu)).

5.1.1. Thermal characteristics

The thermal characteristics of the package are shown in Table 611.

Table 611. Thermal data for the RP2040 QFN 56 package.

\( \theta_{JA} \) (°C/W)\( \Psi_{JT} \) (°C/W)\( \Psi_{JB} \) (°C/W)\( T_J \) (°C)\( T_T \) (°C)\( \theta_{JC} \) (°C/W)\( \theta_{JB} \) (°C/W)
48.000.8029.2042.0041.819.0129.03

5.1.2. Recommended PCB Footprint

Figure 167. Recommended PCB Footprint for the RP2040 QFN-56 package

Figure 168. Package marking format

Figure 168: Package marking format. A square marking area containing a Raspberry Pi logo, the text 'RP2-B2', 'XXXXXX.00', 'YY/WW', and 'TTT'.

The image shows a square marking area on a light gray background. Inside the square, there is a black dot in the top-left corner. To the right of the dot is the Raspberry Pi logo. Below the logo, the text 'RP2-B2' is printed. To the right of 'RP2-B2' is 'YY/WW'. Below 'RP2-B2' is 'XXXXXX.00'. To the right of 'XXXXXX.00' is 'TTT'.

Figure 168: Package marking format. A square marking area containing a Raspberry Pi logo, the text 'RP2-B2', 'XXXXXX.00', 'YY/WW', and 'TTT'.

Table 612. Marking requirements and dimensions

LineStepItemCoord. XCoord. YChar. HeightChar. WidthChar. Space
11Pin 1 Dot0.560.50.5
21Logo3.52.3953.833.05
31RP2-B20.5551.5850.610.370.09
32YY/WW4.2351.5850.610.370.09
41XXXXXX.000.5550.7750.610.370.09
42TTT
(optional)
5.1550.7750.610.370.09

NOTE

At Line 3, Step 1, the "RP2-B2" marking denotes device name "RP2" and silicon revision "B2."

5.2. Storage conditions

In order to preserve the shelf and floor life of bare RP2040 devices, the recommended storage conditions in line with J-STD (020E & 033D) for RP2040 (classified MSL1) should be kept under 30°C and 85% relative humidity.

5.3. Solder profile

RP2040 is a Pb-free part, with a \( T_p \) value of 260°C.

All temperatures refer to the center of the package, measured on the package body surface that is facing up during assembly reflow (live-bug orientation). If parts are reflowed in other than the normal live-bug assembly reflow orientation (i.e., dead-bug), \( T_p \) shall be within \( \pm 2^\circ\text{C} \) of the live-bug \( T_p \) and still meet the \( T_c \) requirements; otherwise, the profile shall be adjusted to achieve the latter.

Figure 169.
Classification profile
(not to scale)

Figure 169: Classification profile diagram. The main graph shows Temperature vs. Time. The curve starts at 25°C, rises through a preheat area (T_smin to T_smax) with a max ramp up rate of 3°C/s, then rises to a peak T_p with a max ramp down rate of 6°C/s. The peak is maintained for time t_p. The temperature then falls. A callout box shows two zoomed-in views of the peak: 'Supplier T_p ≥ T_c' and 'User T_p ≤ T_c', both showing a 5°C tolerance around T_c. The main graph also shows T_c and T_c - 5°C levels.

Supplier \( T_p \geq T_c \)

User \( T_p \leq T_c \)

Max. Ramp Up Rate = 3°C/s
Max. Ramp Down Rate = 6°C/s

Preheat Area

Temperature

Time

Time 25°C to Peak

Time \( t_p \)

Time \( t_s \)

Time \( t \)

Temperature \( T_p \)

Temperature \( T_L \)

Temperature \( T_{smax} \)

Temperature \( T_{smin} \)

Temperature \( T_c \)

Temperature \( T_c - 5^\circ\text{C} \)

Figure 169: Classification profile diagram. The main graph shows Temperature vs. Time. The curve starts at 25°C, rises through a preheat area (T_smin to T_smax) with a max ramp up rate of 3°C/s, then rises to a peak T_p with a max ramp down rate of 6°C/s. The peak is maintained for time t_p. The temperature then falls. A callout box shows two zoomed-in views of the peak: 'Supplier T_p ≥ T_c' and 'User T_p ≤ T_c', both showing a 5°C tolerance around T_c. The main graph also shows T_c and T_c - 5°C levels.

NOTE

Reflow profiles in this document are for classification/preconditioning, and are not meant to specify board assembly profiles. Actual board assembly profiles should be developed based on specific process needs and board designs, and should not exceed the parameters in Table 613 .

Table 613. Solder
profile values

Profile featureValue
Temperature min ( \( T_{smin} \) )150°C
Temperature max ( \( T_{smax} \) )200°C
Time ( \( t_s \) ) from ( \( T_{smin} \) to \( T_{smax} \) )60 – 120 seconds
Ramp-up rate ( \( T_L \) to \( T_p \) )3°C/second max.
Liquidous temperature ( \( T_L \) )217°C
Time ( \( t_L \) ) maintained above \( T_L \)60 to 150 seconds
Peak package body temperature ( \( T_p \) )260°C
Classification temperature ( \( T_c \) )260°C
Time ( \( t_p \) ) within 5°C of the specified classification temperature ( \( T_c \) )30 seconds
Ramp-down rate ( \( T_p \) to \( T_L \) )6°C/second max.
Time 25°C to peak temperature8 minutes max.

5.4. Compliance

RP2040 is compliant to Moisture Sensitivity Level 1.

RP2040 is compliant to the requirement of REACH Substances of Very High Concern (SVHC) that ECHA announced on 25 June 2020.

RP2040 is compliant to the requirement and standard of Controlled Environment-related Substance of RoHS directive (EU) 2011/65/EU and directive (EU) 2015/863.

Package Level reliability qualifications carried out on RP2040:

NOTE

A tin whiskers test is not performed as RP2040 is a bottom only termination device (QFN package) which not applicable to JEDEC standard (JESD201A).

5.5. Pinout

5.5.1. Pin Locations

Figure 170. RP2040
QFN-56 package
pinout

Pinout diagram for RP2040 QFN-56 package showing pin locations and functions.

The diagram shows the top view of the RP2040 QFN-56 package. The pins are arranged in a square pattern around a central square labeled 'GND'. The pins are numbered 1 to 56. The functions of the pins are as follows:

PinFunction
1IOVDD
2GPI00
3GPI01
4GPI02
5GPI03
6GPI04
7GPI05
8GPI06
9GPI07
10IOVDD
11GPI08
12GPI09
13GPI010
14GPI011
15GPI012
16GPI013
17GPI014
18GPI015
19TESTEN
20XIN
21XOUT
22IOVDD
23DVDD
24SWCLK
25SWDIO
26RUN
27GPI016
28GPI017
29GPI018
30GPI019
31GPI020
32GPI021
33IOVDD
34GPI022
35GPI023
36GPI024
37GPI025
38GPI026/ADC0
39GPI027/ADC1
40GPI028/ADC2
41GPI029/ADC3
42IOVDD
43ADC_AVDD
44VREG_VIN
45VREG_VOUT
46USB_DM
47USB_DP
48USB_VDD
49IOVDD
50DVDD
51QSPL_SD3
52QSPL_SCLK
53QSPL_SD0
54QSPL_SD2
55QSPL_SD1
56QSPL_SS_N
Pinout diagram for RP2040 QFN-56 package showing pin locations and functions.

5.5.2. Pin Definitions

5.5.2.1. Pin Types

In the following GPIO Pin table (Table 615), the pin types are defined as shown below.

Table 614. Pin Types

Pin TypeDirectionDescription
Digital InInput onlyStandard Digital. Programmable Pull-Up, Pull-Down, Slew Rate, Schmitt Trigger and Drive Strength. Default Drive Strength is 4mA.
Digital IOBi-directional
Digital In (FT)Input onlyFault Tolerant Digital. These pins are described as Fault Tolerant, which in this case means that very little current flows into the pin whilst it is below 3.63V and IOVDD is 0V. There is also enhanced ESD protection on these pins. Programmable Pull-Up, Pull-Down, Slew Rate, Schmitt Trigger and Drive Strength. Default Drive Strength is 4mA.
Digital IO (FT)Bi-directional
Digital IO / AnalogueBi-directional (digital), Input (Analogue)Standard Digital and ADC input. Programmable Pull-Up, Pull-Down, Slew Rate, Schmitt Trigger and Drive Strength. Default Drive Strength is 4mA.
USB IOBi-directionalThese pins are for USB use, and contain internal pull-up and pull-down resistors, as per the USB specification. Note that external 27Ω series resistors are required for USB operation.
Analogue (XOSC)Oscillator input pins for attaching a 12MHz crystal. Alternatively, XIN may be driven by a square wave.

5.5.2.2. Pin List

Table 615. GPIO pins

NameNumberTypePower DomainReset StateDescription
GPIO02Digital IO (FT)IOVDDPull-DownUser IO
GPIO13Digital IO (FT)IOVDDPull-DownUser IO
GPIO24Digital IO (FT)IOVDDPull-DownUser IO
GPIO35Digital IO (FT)IOVDDPull-DownUser IO
GPIO46Digital IO (FT)IOVDDPull-DownUser IO
GPIO57Digital IO (FT)IOVDDPull-DownUser IO
GPIO68Digital IO (FT)IOVDDPull-DownUser IO
GPIO79Digital IO (FT)IOVDDPull-DownUser IO
GPIO811Digital IO (FT)IOVDDPull-DownUser IO
GPIO912Digital IO (FT)IOVDDPull-DownUser IO
GPIO1013Digital IO (FT)IOVDDPull-DownUser IO
GPIO1114Digital IO (FT)IOVDDPull-DownUser IO
GPIO1215Digital IO (FT)IOVDDPull-DownUser IO
GPIO1316Digital IO (FT)IOVDDPull-DownUser IO
GPIO1417Digital IO (FT)IOVDDPull-DownUser IO
GPIO1518Digital IO (FT)IOVDDPull-DownUser IO
NameNumberTypePower DomainReset StateDescription
GPIO1627Digital IO (FT)IOVDDPull-DownUser IO
GPIO1728Digital IO (FT)IOVDDPull-DownUser IO
GPIO1829Digital IO (FT)IOVDDPull-DownUser IO
GPIO1930Digital IO (FT)IOVDDPull-DownUser IO
GPIO2031Digital IO (FT)IOVDDPull-DownUser IO
GPIO2132Digital IO (FT)IOVDDPull-DownUser IO
GPIO2234Digital IO (FT)IOVDDPull-DownUser IO
GPIO2335Digital IO (FT)IOVDDPull-DownUser IO
GPIO2436Digital IO (FT)IOVDDPull-DownUser IO
GPIO2537Digital IO (FT)IOVDDPull-DownUser IO
GPIO26 / ADC038Digital IO /
Analogue
IOVDD /
ADC_AVDD
Pull-DownUser IO or ADC
input
GPIO27 / ADC139Digital IO /
Analogue
IOVDD /
ADC_AVDD
Pull-DownUser IO or ADC
input
GPIO28 / ADC240Digital IO /
Analogue
IOVDD /
ADC_AVDD
Pull-DownUser IO or ADC
input
GPIO29 / ADC341Digital IO /
Analogue
IOVDD /
ADC_AVDD
Pull-DownUser IO or ADC
input

Table 616. QSPI pins

NameNumberTypePower DomainReset StateDescription
QSPI_SD351Digital IOIOVDDQSPI data
QSPI_SCLK52Digital IOIOVDDPull-DownQSPI clock
QSPI_SD053Digital IOIOVDDQSPI data
QSPI_SD254Digital IOIOVDDQSPI data
QSPI_SD155Digital IOIOVDDQSPI data
QSPI_CSn56Digital IOIOVDDPull-UpQSPI chip select

Table 617. Crystal oscillator pins

NameNumberTypePower DomainDescription
XIN20Analogue (XOSC)IOVDDCrystal oscillator. XIN may also be driven by a square wave.
XOUT21Analogue (XOSC)IOVDDCrystal oscillator.

Table 618. Serial wire debug pins

NameNumberTypePower DomainReset StateDescription
SWCLK24Digital In (FT)IOVDDPull-UpDebug clock
SWD25Digital IO (FT)IOVDDPull-UpDebug data

Table 619. Miscellaneous pins

NameNumberTypePower DomainReset StateDescription
RUN26Digital In (FT)IOVDDPull-UpChip enable /
reset
NameNumberTypePower DomainReset StateDescription
TESTEN19Digital InIOVDDPull-DownTest enable
(connect to Gnd)

Table 620. USB pins

NameNumberTypePower DomainDescription
USB_DP47USB IOUSB_VDDUSB Data +ve. 27Ω series resistor required for USB operation
USB_DM46USB IOUSB_VDDUSB Data -ve. 27Ω series resistor required for USB operation

Table 621. Power supply pins

NameNumber(s)Description
IOVDD1, 10, 22, 33, 42, 49IO supply
DVDD23, 50Core supply
VREG_VIN44Voltage regulator input supply
VREG_VOUT45Voltage regulator output
USB_VDD48USB supply
ADC_AVDD43ADC supply
GND57Common ground connection via central pad

5.5.3. Pin Specifications

The following electrical specifications are obtained from characterisation over the specified temperature and voltage ranges, as well as process variation, unless the specification is marked as 'Simulated'. In this case, the data is for information purposes only, and is not guaranteed.

5.5.3.1. Absolute Maximum Ratings

Table 622. Absolute maximum ratings for digital IO (Standard and Fault Tolerant)

ParameterSymbolMinimumMaximumUnitsComment
I/O Supply VoltageIOVDD-0.53.63V
Voltage at IOV PIN-0.5IOVDD + 0.5V

5.5.3.2. ESD Performance

Table 623. ESD performance for all pins, unless otherwise stated

ParameterSymbolMaximumUnitsComment
Human Body ModelHBM2kVCompliant with JEDEC specification JS-001-2012 (April 2012)
ParameterSymbolMaximumUnitsComment
Human Body Model
Digital (FT) pins only
HBM4kVCompliant with JEDEC specification JS-001-2012 (April 2012)
Charged Device ModelCDM500VCompliant with JESD22-C101E (December 2009)

5.5.3.3. Thermal Performance

Table 624. Thermal Performance

ParameterSymbolMinimumTypicalMaximumUnitsComment
Case Temperature\( T_C \)-4085°C

5.5.3.4. IO Electrical Characteristics

Table 625. Digital IO characteristics - Standard and FT unless otherwise stated

ParameterSymbolMinimumMaximumUnitsComment
Pin Input Leakage Current\( I_{IN} \)1μA
Input Voltage High @ IOVDD=1.8V\( V_{IH} \)\( 0.65 * IOVDD \)\( IOVDD + 0.3 \)V
Input Voltage High @ IOVDD=2.5V\( V_{IH} \)1.7\( IOVDD + 0.3 \)V
Input Voltage High @ IOVDD=3.3V\( V_{IH} \)2\( IOVDD + 0.3 \)V
Input Voltage Low @ IOVDD=1.8V\( V_{IL} \)-0.3\( 0.35 * IOVDD \)V
Input Voltage Low @ IOVDD=2.5V\( V_{IL} \)-0.30.7V
Input Voltage Low @ IOVDD=3.3V\( V_{IL} \)-0.30.8V
Input Hysteresis Voltage @ IOVDD=1.8V\( V_{HYS} \)\( 0.1 * IOVDD \)VSchmitt Trigger enabled
Input Hysteresis Voltage @ IOVDD=2.5V\( V_{HYS} \)0.2VSchmitt Trigger enabled
Input Hysteresis Voltage @ IOVDD=3.3V\( V_{HYS} \)0.2VSchmitt Trigger enabled
Output Voltage High @ IOVDD=1.8V\( V_{OH} \)1.24IOVDDV\( I_{OH} = 2, 4, 8 \) or 12mA depending on setting
ParameterSymbolMinimumMaximumUnitsComment
Output Voltage High @ IOVDD=2.5V\( V_{OH} \)1.78IOVDDV\( I_{OH} = 2, 4, 8 \) or 12mA depending on setting
Output Voltage High @ IOVDD=3.3V\( V_{OH} \)2.62IOVDDV\( I_{OH} = 2, 4, 8 \) or 12mA depending on setting
Output Voltage Low @ IOVDD=1.8V\( V_{OL} \)00.3V\( I_{OL} = 2, 4, 8 \) or 12mA depending on setting
Output Voltage Low @ IOVDD=2.5V\( V_{OL} \)00.4V\( I_{OL} = 2, 4, 8 \) or 12mA depending on setting
Output Voltage Low @ IOVDD=3.3V\( V_{OL} \)00.5V\( I_{OL} = 2, 4, 8 \) or 12mA depending on setting
Pull-Up Resistance\( R_{PU} \)5080k \( \Omega \)
Pull-Down Resistance\( R_{PD} \)5080k \( \Omega \)
Maximum Total IOVDD current\( I_{IOVDD\_MAX} \)50mASum of all current being sourced by GPIO and QSPI pins
Maximum Total VSS current due to IO (IOVSS)\( I_{IOVSS\_MAX} \)50mASum of all current being sunk into GPIO and QSPI pins

Table 626. USB IO characteristics

ParameterSymbolMinimumMaximumUnitsComment
Pin Input Leakage Current\( I_{IN} \)1\( \mu \) A
Single Ended Input Voltage High\( V_{IHSE} \)2V
Single Ended Input Voltage Low\( V_{ILSE} \)0.8V
Differential Input Voltage High\( V_{IHDIFF} \)0.2V
Differential Input Voltage Low\( V_{ILDIFF} \)-0.2V
Output Voltage High\( V_{OH} \)2.8USB_VDDV
Output Voltage Low\( V_{OL} \)00.3V
Pull-Up Resistance - RPU2\( R_{PU2} \)0.8731.548k \( \Omega \)
ParameterSymbolMinimumMaximumUnitsComment
Pull-Up Resistance
- RPU1&2
R PU1&21.3983.063kΩ
Pull-Down
Resistance
R PD14.2515.75kΩ

Table 627. ADC characteristics

ParameterSymbolMinimumMaximumUnitsComment
ADC Input Voltage RangeV PIN_ADC0ADC_AVDDV
Effective Number of BitsENOB8.7bitsSee Section 4.9.3
Resolved Bits12bits
ADC Input ImpedanceR IN_ADC100kΩ

Table 628. Oscillator pin characteristics when using a Square Wave input

ParameterSymbolMinimumMaximumUnitsComment
Input Voltage HighV IH0.65*IOVDDIOVDD + 0.3VXIN only. XOUT floating
Input Voltage LowV IL00.35*IOVDDVXIN only. XOUT floating

See Section 2.16 for more details on the Oscillator, and Minimal Design Example for information on crystal usage.

5.5.3.5. Interpreting GPIO output voltage specifications

The GPIOs on RP2040 have four different output drive strengths, which are nominally called 2, 4, 8 and 12mA modes. These are not hard limits, nor do they mean that they will always be sourcing (or sinking) the selected amount of milliamps. The amount of current a GPIO sources or sinks is dependent on the load attached to it. It will attempt to drive the output to the IOVDD level (or 0V in the case of a logic 0), but the amount of current it is able to source is limited, which will be dependent on the selected drive strength. Therefore the higher the current load is, the lower the voltage will be at the pin. At some point, the GPIO will be sourcing so much current, that the voltage is so low, it won't be recognised as a logic 1 by the input of a connected device. The purpose of the output specifications in Table 625 are to try and quantify how much lower the voltage can be expected to be, when drawing specified amounts of current from the pin.

The Output High Voltage (V OH ) is defined as the lowest voltage the output pin can be when driven to a logic 1 with a particular selected drive strength; e.g., 4mA being sourced by the pin whilst in 4mA drive strength mode. The Output Low Voltage is similar, but with a logic 0 being driven.

In addition to this, the sum of all the IO currents being sourced (i.e. when outputs are being driven high) from the IOVDD bank (essentially the GPIO and QSPI pins), must not exceed I IOVDD_MAX . Similarly, the sum of all the IO currents being sunk (i.e. when the outputs are being driven low) must not exceed I IOVSS_MAX .

Figure 171. Typical Current vs Voltage curves of a GPIO output.

Figure 171: Typical GPIO Output High IV curve and Typical GPIO Output Low IV curve. The top graph shows Voltage at GPIO pin (V) vs Current sourced by GPIO (mA) for settings of 2mA, 4mA, 8mA, and 12mA. The bottom graph shows Voltage at GPIO pin (V) vs Current sunk by GPIO (mA) for the same settings. Both graphs include minimum VOH and maximum VOL limits indicated by red dotted lines.

The figure consists of two graphs. The top graph, titled 'Typical GPIO Output High IV curve', plots Voltage at GPIO pin (V) on the y-axis (1 to 3.5) against Current sourced by GPIO (mA) on the x-axis (0 to 30). It shows four curves for different drive settings: 2mA (blue), 4mA (orange), 8mA (grey), and 12mA (yellow). A red dotted line indicates the Minimum VOH limit at approximately 2.6V. The bottom graph, titled 'Typical GPIO Output Low IV curve', plots Voltage at GPIO pin (V) on the y-axis (0 to 1.2) against Current sunk by GPIO (mA) on the x-axis (0 to 30). It shows four curves for the same drive settings. A red dotted line indicates the Maximum VOL limit at approximately 0.28V.

Figure 171: Typical GPIO Output High IV curve and Typical GPIO Output Low IV curve. The top graph shows Voltage at GPIO pin (V) vs Current sourced by GPIO (mA) for settings of 2mA, 4mA, 8mA, and 12mA. The bottom graph shows Voltage at GPIO pin (V) vs Current sunk by GPIO (mA) for the same settings. Both graphs include minimum VOH and maximum VOL limits indicated by red dotted lines.

Figure 171 shows the effect on the output voltage as the current load on the pin increases. You can clearly see the effect of the different drive strengths; the higher the drive strength, the closer the output voltage is to IOVDD (or 0V) for a given current. The minimum \( V_{OH} \) and maximum \( V_{OL} \) limits are shown in red. You can see that at the specified current for each drive strength, the voltage is well within the allowed limits, meaning that this particular device could drive a lot more current and still be within \( V_{OH}/V_{OL} \) specification. This is a typical part at room temperature, there will be a spread of other devices which will have voltages much closer to this limit. Of course, if your application doesn't need such tightly controlled voltages, then you can source or sink more current from the GPIO than the selected drive strength setting, but experimentation will be required to determine if it indeed safe to do so in your application, as it will be outside the scope of this specification.

5.5.3.6. Pin IO Delays

These delays include PIO's input/output mapping logic, IO muxing, and the actual pad delays into a nominal load of 5 pF. Min/max is over the extremes of process variation, voltage (1.1 V +/- 10%) and temperature (-40 C to 125 C).

These delays assume an IOVDD of 1.8 V, with PADS_VSEL set. At IOVDD = 3.3 V, the delay is significantly lower, and the range is smaller.

The flops themselves have a typical setup time of 10.6 ps and hold time of 2.2 ps. The IO delays between flops and pads must be taken into account.

For minimum and maximum output delays, from CLK_SYS arriving at any flop in PIO to the data being valid at a particular GPIO pad see Table 629.

Table 629. Pin minimum and maximum delays from flop to pad, in nanoseconds.

Pad outputMin delay (ns)Max delay (ns)
GPIO02.277.10
GPIO12.317.07
Pad outputMin delay (ns)Max delay (ns)
GPIO22.337.08
GPIO32.247.00
GPIO42.307.07
GPIO52.347.10
GPIO62.327.10
GPIO72.397.09
GPIO82.347.09
GPIO92.387.08
GPIO102.337.07
GPIO112.367.08
GPIO122.357.04
GPIO132.317.08
GPIO142.387.06
GPIO152.337.05
GPIO162.347.09
GPIO172.377.09
GPIO182.377.04
GPIO192.277.10
GPIO202.387.09
GPIO212.057.10
GPIO222.347.07
GPIO232.167.05
GPIO242.127.06
GPIO252.267.10
GPIO262.327.09
GPIO272.267.08
GPIO282.347.09
GPIO292.307.07

For minimum and maximum input delays, from pad input to the input synchroniser, see Table 630 .

Table 630. Pin minimum and maximum delays from pad input to input synchroniser, in nanoseconds.

Pad outputMin delay (ns)Max delay (ns)
GPIO11.895.22
GPIO21.845.25
GPIO31.835.24
GPIO41.905.17
GPIO51.905.14
Pad outputMin delay (ns)Max delay (ns)
GPIO61.915.19
GPIO71.915.14
GPIO81.955.14
GPIO91.965.12
GPIO101.955.11
GPIO111.925.16
GPIO121.925.15
GPIO131.945.16
GPIO141.905.18
GPIO151.925.15
GPIO161.955.13
GPIO171.955.12
GPIO181.955.10
GPIO191.955.12
GPIO212.074.98
GPIO231.985.06
GPIO241.975.07
GPIO251.975.08
GPIO261.965.12
GPIO271.945.13
GPIO281.955.13
GPIO291.995.10

For minimum and maximum input delays over all corners, from pad input to state machine IN data flops (synchronisers bypassed) see Table 631 .

Table 631. Pin minimum and maximum delays from pad input to state machine IN data flops (synchronisers bypassed), in nanoseconds.

Pad inputMin delay (ns)Max delay (ns)
GPIO12.225.45
GPIO22.255.49
GPIO32.235.18
GPIO42.245.41
GPIO52.305.65
GPIO62.255.48
GPIO72.265.50
GPIO82.305.51
GPIO92.255.68
GPIO102.345.71
GPIO112.285.47
Pad inputMin delay (ns)Max delay (ns)
GPIO122.295.40
GPIO132.255.47
GPIO142.245.41
GPIO152.235.47
GPIO162.305.42
GPIO172.285.44
GPIO182.285.34
GPIO192.305.50
GPIO212.165.79
GPIO232.335.53
GPIO242.285.60
GPIO252.295.53
GPIO262.285.38
GPIO272.275.39
GPIO282.245.28
GPIO292.335.47

5.5.3.6.1. Effects of IOVDD

All of the IO delays given above assume IOVDD = 1.8V. Increasing IOVDD to 3.3V reduces the pad delays quite significantly, and the pad delay is a large fraction of the delays reported above. See Table 632 for a summary of best and worst pad delays at 1.8V and 3.3V.

Table 632. Best and worst pad delays at 1.8V and 3.3V.

Path typeIOVDDMin delay (ns)Max delay (ns)
Output1.8V1.543.65
Output3.3V1.112.14
Input1.8V0.631.06
Input3.3V0.470.76

Changing IOVDD does not affect any logic in the core domain, so these differences can be added to the IO delay tables above to estimate the IO delay ranges at IOVDD = 3.3V (see Table 633 ).

Table 633. IO delay ranges at IOVDD = 3.3V.

Path groupIOVDDMin delay (ns)Max delay (ns)
Output1.8V2.127.10
Output3.3V1.695.59
Input to sync1.8V1.835.25
Input to sync3.3V1.674.95
Input to SM1.8V2.165.79
Input to SM3.3V2.005.49

5.6. Power Supplies

Table 634. Power Supply Specifications

Power SupplySuppliesMinTypMaxUnits
IOVDD aDigital IO1.621.8 / 3.33.63V
DVDD bDigital core1.051.11.16V
VREG_VINVoltage regulator1.621.8 / 3.33.63V
USB_VDDUSB PHY3.1353.33.63V
ADC_AVDD cADC1.623.33.63V

a If IOVDD <2.5V, GPIO VOLTAGE_SELECT registers should be adjusted accordingly. See Section 2.9 for details.

b Short term transients should be within +/-100mV. If using 200MHz for clk_sys as described in Section 2.15.3 , set DVDD to 1.15V.

c ADC performance will be compromised at voltages below 2.97V

5.7. Power Consumption

5.7.1. Peripheral power consumption

Baseline readings are taken with only clock sources and essential peripherals ( BUSCTRL , BUSFAB , VREG , Resets, ROM, SRAMs) active in the WAKE_EN0 / WAKE_EN1 registers. Clocks are set to default clock settings. Each peripheral is activated in turn by enabling all clock sources for the peripheral in the WAKE_EN0 / WAKE_EN1 registers. Current consumption is the increase in current when the peripheral clocks are enabled.

Table 635. Baseline power consumption

PeripheralTypical DVDD Current Consumption (µA/MHz)
DMA2.6
I2C03.9
I2C13.8
IO + Pads23.6
PIO012.3
PIO112.5
PWM5.0
RTC1.1
SIO1.9
SPIO1.7
SPI11.8
Timer1.2
UART03.5
UART13.7
Watchdog1.0
XIP37.6

Because of fixed external reference clocks of 48 MHz, as well as the variable system clock input, ADC and USBCTRL power consumption does not vary linearly with system clock (as it does for other peripherals which only have system and/or peripheral clock inputs). Absolute DVDD current consumption of the ADC and USBCTRL blocks at standard clocks (system clock of 125 MHz) is given below:

Table 636. Baseline power consumption for ADC and USBCTRL

PeripheralTypical DVDD Current Consumption (µA/MHz)
ADC0.1
USBCTRL1.3

5.7.2. Power consumption for typical user cases

The following data shows the current consumption of various power supplies on 3 each of typical (tt), fast (ff) and slow (ss) corner RP2040 devices, with four different software use-cases.

Image: Note icon

NOTE

For power consumption of the Raspberry Pi Pico, please see the Raspberry Pi Pico Datasheet .

Firstly, 'Popcorn' (Media player demo) using the VGA, SD Card, and Audio board. This demo uses VGA video, I2S audio and 4-bit SD Card access, with a system clock frequency of 48MHz.

Image: Note icon

NOTE

For more details of the VGA board see the Hardware design with RP2040 book.

Secondly, the BOOTSEL mode of RP2040. These measurements are made both with and without USB activity on the bus, using a Raspberry Pi 4 as a host.

The third use-case uses the hello_dormant binary which puts RP2040 into a low power state, DORMANT mode.

The final use-case uses the hello_sleep binary code which puts RP2040 into a low power state, SLEEP mode.

Table 637 has two columns per power supply, 'Typical Average Current' and 'Maximum Average Current'. The former is the current averaged over several seconds that you might expect a typical RP2040 to consume at room temperature and nominal voltage (e.g., DVDD=1.1V, IOVDD=3.3V, etc). The 'Maximum Average Current' is the maximum current consumption (again averaged over several seconds) you might expect to see on a worst-case RP2040 device, across the temperature extremes, and maximum voltage (e.g., DVDD=1.21V, etc).

Image: Note icon

NOTE

The 'Popcorn' consumption measurements depend on the video being displayed at the time. The 'Typical' values are obtained over several seconds of video, with varied colour and intensity. The 'Maximum' values are measured during periods of white video, when the required current is at its highest.

Table 637. Power Consumption

Software Use-caseTypical Average DVDD CurrentMax. Average DVDD currentTypical Average IOVDD CurrentMax. Average IOVDD currentTypical Average USB_VDD CurrentMax. Average USB_VDD currentUnits
Popcorn10.916.624.835.5--mA
BOOTSEL mode - Active9.414.71.24.31.42.0mA
BOOTSEL mode - Idle9.014.31.24.30.20.6mA
Dormant0.184.2----mA
Software Use-caseTypical Average DVDD CurrentMax. Average DVDD currentTypical Average IOVDD CurrentMax. Average IOVDD currentTypical Average USB_VDD CurrentMax. Average USB_VDD currentUnits
Sleep0.394.5----mA

5.7.2.1. Power Consumption versus frequency

To give an indication of the relationship between the core frequency that RP2040 is operating at, and the current consumed by the DVDD supply, Figure 172 shows the measured results of a typical RP2040 device, continuously running FFT calculations on both cores, at various core clock frequencies. Figure 172 also shows the effects of case temperature, and DVDD voltage upon the current consumption.

Figure 172. DVDD Current vs Core Frequency of a typical RP2040 device, whilst running FFT calculations

Line graph showing DVDD Current (mA) vs Core Frequency (MHz) for a typical RP2040 device running FFT calculations. The graph shows three sets of lines for Cold, Room Temp, and Hot conditions, each with three lines for DVDD voltages of 0.99V, 1.1V, and 1.21V. Current increases linearly with frequency and is higher for higher temperatures and higher DVDD voltages.

The graph plots DVDD Current (mA) on the y-axis (0 to 40) against Core Frequency (MHz) on the x-axis (10 to 150). There are nine data series representing combinations of three temperatures (Cold, Room Temp, Hot) and three DVDD voltages (0.99V, 1.1V, 1.21V). The lines show a positive linear correlation between frequency and current. Higher temperatures and higher DVDD voltages result in higher current consumption across all frequencies.

Core Frequency (MHz)Cold: 0.99VCold: 1.1VCold: 1.21VRoom Temp: 0.99VRoom Temp: 1.1VRoom Temp: 1.21VHot: 0.99VHot: 1.1VHot: 1.21V
104.55.56.54.55.56.54.55.56.5
5012.514.516.512.514.516.512.514.516.5
9020.522.524.520.522.524.520.522.524.5
13028.530.532.528.530.532.528.530.532.5
15032.534.536.532.534.536.532.534.536.5
Line graph showing DVDD Current (mA) vs Core Frequency (MHz) for a typical RP2040 device running FFT calculations. The graph shows three sets of lines for Cold, Room Temp, and Hot conditions, each with three lines for DVDD voltages of 0.99V, 1.1V, and 1.21V. Current increases linearly with frequency and is higher for higher temperatures and higher DVDD voltages.

Appendix A: Register Field Types

Standard types

RW:

RO:

WO:

Clear types

SC

WC

FIFO types

These fields are used for reading and writing data to and from FIFOs. Accompanying registers provide FIFO control and status. There is no fixed format for the control and status registers, as they are specific to each FIFO interface.

RWF

RF

WF

Appendix B: Errata

Hardware blocks are listed alphabetically. Errata are listed numerically under the relevant block.

Bootrom

RP2040-E9

ReferenceRP2040-E9
SummaryROM bootloader cannot boot directly into XIP cache-as-SRAM
Description

The XIP cache can be used as an additional 16kB SRAM bank when XIP caching is disabled ( Section 2.6.3.1 ). The UF2 bootloader supports RAM-only UF2 binaries, which it loads directly into memory, and enters via a watchdog reboot. A single UF2 binary can initialise both the XIP cache contents and main system memory, and the cache is disabled by the bootloader, so that cache contents be written.

However, the watchdog reset re-enables the cache, so booting directly into the cache-as-SRAM alias causes an immediate bus fault. The cache contents are preserved, but can not be accessed immediately post-boot.

Workaround

Add code in main SRAM to re-disable XIP caching before accessing the cache-as-SRAM alias. When entering a RAM-only UF2 binary, the bootloader selects the lowest loaded address in either main SRAM or cache-as-SRAM as the entry point, preferring main SRAM if both are loaded.

Additionally, if the 0x15... segment is written immediately post-boot, a dummy read of the FLUSH register is required, so that no cache-as-SRAM writes take place during the tag memory flush triggered by the watchdog (see Section 2.6.3.2 ).

AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byDocumentation

RP2040-E14

ReferenceRP2040-E14
SummarySparse or mis-aligned flash-binary UF2 may not be written to flash correctly by the UF2 bootloader
Description

A RP2040 UF2 file consists of 256-byte pages of data, each marked to be written at a certain address by the UF2 bootloader. A flash-binary UF2 is one of these for which every 256-byte page is marked to be written at a 256-byte-aligned address in flash.

When writing flash, an entire 4kB flash sector must be erased at a time before any pages within that sector can be (re-)written. The UF2 bootloader does not require the flash-binary UF2 to include data for all pages within a sector. In that case the whole sector will first be erased, any present pages will be written, and the rest of the 4kB sector will be left undefined.

This mechanism works as expected when the partially-filled sector is at the end of the binary, which is of course commonplace, as a binary does not need to be a multiple of 4kB long.

If however, the partially-filled sector occurs at the start of the binary (i.e. the binary is not aligned on a 4kB page) or if a partially-filled sector appears in the middle of the binary (i.e. the binary is sparse/non-contiguous), then the UF2 file may be written incorrectly.

Note that the vast majority of UF2s generated by the SDK are indeed aligned on a 4kB boundary and contiguous, however it is possible for the SDK to produce a misaligned or non-contiguous binary by modifying the linker scripts, or putting extreme alignment requirements on static data. It is also possible that other languages or tools might produce binaries that are not 4kB-aligned or contiguous.

Workaround

The workaround is to include data for all the pages in any 4kB sector (other than the last) that contains data for some pages.

This is handled for you automatically by the elf2uf2 tool in the SDK version 1.3.1 onwards, which explicitly adds zero-filled pages to the appropriate partially-filled sectors.

AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byDocumentation / Software

Clocks

RP2040-E7

ReferenceRP2040-E7
SummaryROSC and XOSC COUNT registers are unreliable
DescriptionThe ROSC and XOSC COUNT registers are intended to be used in the configuration of components like PHYs and PLLs where microsecond scale delays are required and NOP loops are inadequate because the clk_sys frequency is variable. However due to a synchronisation issue the ROSC: COUNT and XOSC: COUNT registers are unreliable.
WorkaroundDo not use ROSC: COUNT or XOSC: COUNT
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byNot fixed, do not use. These registers are not used by the C SDK.

RP2040-E10

ReferenceRP2040-E10
SummaryBADWRITE field in ROSC STATUS register is unreliable
DescriptionThe BADWRITE field in the ROSC STATUS register was intended to report when invalid values had been written to other ROSC registers. However due to internal bugs the ROSC: STATUS . BADWRITE field is unreliable.
WorkaroundDo not use ROSC: STATUS . BADWRITE field
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byNot fixed, do not use. This field is not used by the C SDK.

DMA

RP2040-E12

ReferenceRP2040-E12
SummaryReading DMA WRITE_ADDR and READ_ADDR registers when an address-wrapping or non-incrementing transfer sequence is in progress gives wrong values
Description

The DMA's internal WRITE_ADDR and READ_ADDR registers are incremented every time the DMA issues a new address to its bus pipeline. If the processor reads these registers whilst a sequence of transfers is in progress, the value reported by the DMA is adjusted downward by the number of in-flight transfers (i.e. issued to the bus pipeline and not yet completed) times the individual transfer size in bytes.

This logic was added to ensure that reading READ_ADDR and WRITE_ADDR reflects addresses where the read/write has completed , not merely where the address has been issued. This logic does not take into account that READ_ADDR and WRITE_ADDR do not increment linearly for some transfer modes, specifically, when CTRL.INCR_WRITE == 0, CTRL.INCR_READ == 0 or CTRL.RING_SIZE != 0.

Workaround

Instead of checking READ_ADDR or WRITE_ADDR to monitor the progress of a transfer sequence, check TRANS_COUNT .

TRANS_COUNT has similar in-flight adjustment logic, but is not affected by this erratum because it always decrements linearly. The correct values of READ_ADDR and WRITE_ADDR can be calculated based on their initial values and TRANS_COUNT .

AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byDocumentation

RP2040-E13

ReferenceRP2040-E13
SummaryAfter aborting a channel, the ABORT status clears prematurely, and an interrupt may be asserted
Description

The DMA ABORT register is used to cancel an ongoing sequence of transfers, for example when a channel is stuck on an inactive peripheral DREQ. If, at the point the abort is triggered, the channel currently has any transfers in flight (i.e. the read cycle of the transfer has taken place, but the write cycle has not), the ABORT bit does not wait for these in-flight transfers to complete before clearing.

When the in-flight transfers complete, because the ABORT bit was prematurely cleared, the DMA treats this as a normal completion. This sets the channel's interrupt status flag, assuming CTRL.IRQ_QUIET has not been set.

WorkaroundBefore aborting a channel, clear its interrupt enable. After aborting a channel, poll the CTRL.BUSY bit to wait for completion (not the ABORT bit), clear the spurious IRQ, and restore the interrupt enable.
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed bySoftware

GPIO / ADC

RP2040-E6

ReferenceRP2040-E6
SummaryGPIO digital inputs not disabled for ADC pins by default
DescriptionGPIO26-29 are shared with ADC inputs AIN0-3. The GPIO digital input is enabled after RUN is released. If the pins are connected to an analogue signal to measure, there could be unexpected signal levels on these pads. This is unlikely to cause a problem as the digital inputs have hysteresis enabled by default.
WorkaroundIf analogue inputs are used, the digital input should be disabled as early as possible after startup. This is done in the RP2040B2 bootrom and early on in SDK platform setup code on RP2040B0 and RP2040B1. If user wishes to use digital inputs, they must be enabled.
AffectsRP2040B0, RP2040B1
Fixed byRP2040B2 bootrom. Fixed on RP2040B0 and RP2040B1 in SDK. Custom user code should disable these inputs early on.

RP2040-E11

ReferenceRP2040-E11
SummaryDNL error peaks in ADC
DescriptionThe RP2040 ADC has a DNL that is mostly flat, and below 1 LSB. However at four values – 512, 1,536, 2,560, and 3,584 – the ADC's DNL error peaks above this value. The ENOB for the ADC has been reduced from 9-bits (simulated) to 8.7-bits (measured), see Section 4.9.3 . The DNL errors will somewhat limit the performance of the ADC dependent on use case.
WorkaroundNone
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byNot fixed.

USB

RP2040-E2

ReferenceRP2040-E2
SummaryUSB device endpoint abort is not cleared.
DescriptionThe USB device controller ( Section 4.1 ) has the ability to abort any pending transactions on an endpoint by setting that endpoint's bit in the EP_ABORT register. Due to a logic error, the USB device controller will reply with NAKs forever on all endpoints if a transaction is initiated for any endpoint with the EP_ABORT bit set.
WorkaroundDo not use the EP_ABORT bits.
AffectsRP2040B0, RP2040B1
Fixed byRP2040B2

RP2040-E3

ReferenceRP2040-E3
SummaryUSB host: interrupt endpoint buffer done flag can be set with incorrect buffer select.
DescriptionThe USB host has two types of transactions: normal software initiated transfer, and interrupt transfers, where the host polls an interrupt endpoint after a specific amount of time. For example, polling a mouse every 1ms to check for movement. Interrupt transfer are single buffered, but the controller doesn't reset the buffer selector to zero. This means that if a software initiated transfer happened then the interrupt transfer can potentially raise the buffer done flag with BUF1 selected instead of BUF0 . The fix is to ignore the BUFF_CPU_SHOULD_HANDLE register for interrupt endpoints.
Workaround
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed bySoftware

RP2040-E4

ReferenceRP2040-E4
SummaryUSB host writes to upper half of buffer status in single buffered mode.
DescriptionThe USB host maintains a buffer selector which switches between BUF0 and BUF1 . This should only be toggled in double buffered mode but is toggled in single buffered mode too. For a transaction lasting multiple packets (i.e. length more than 8 bytes in low speed mode, and length more than 64 bytes in full speed mode), the buffer status can be written back to the BUF1 half of the status register when the buffer select is incorrectly set to BUF1 . Note this does not affect reading new buffer information from the buffer control register, as the controller ignores the buffer selector in single buffered mode when reading the buffer control register.
WorkaroundShift endpoint control register to the right by 16 bits if the buffer selector is BUF1 . You can use BUFF_CPU_SHOULD_HANDLE find the value of the buffer selector when the buffer was marked as done.
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed bySoftware

RP2040-E5

ReferenceRP2040-E5
SummaryUSB device fails to exit RESET state on busy USB bus.
Description

The USB bus RESET state is triggered by the host sending SE0 for 10ms to the device. The USB device controller requires 800µs of idle ( J-state ) after a bus reset before moving to the CONNECTED state. Without this idle time, the USB device does not connect and will not receive any packets from the host, and so does not enumerate.

A device reset happens just after the device is plugged in. Although a host will wait before talking to a newly-reset device, other devices attached to the same USB hub may also be communicating with the host.

USB 2.0 and USB 3.0 hubs have one or more transaction translators, which facilitate low speed and full speed transactions on a higher speed bus. It depends on the hub design, but a transaction translator is usually shared between a few ports.

As the RP2040 USB device is full speed, its traffic when connected to a hub will come via a transaction translator. This means that if you have another device plugged in next to an RP2040, the RP2040 is likely to see some messages from the host addressed to the other device. If the device is not very active, for example, a mouse that is polled every 8ms, this is not a problem. However some devices, such as a USB serial port, are polled every 30-50µs. In this case the bus is very active, and will cause the RP2040 to never exit RESET state and not connect.

There is a hardware fix in RP2040B2 which avoids the need for 800µs of IDLE time after RESET state.

There is a software workaround for this issue (see workaround section). A user can also work around this by closing the USB serial port or any other offending devices while connecting their RP2040 and then re-opening their USB serial port.

On a larger hub, the problem may be fixed by moving the RP2040 far away (onto a different transaction translator) from the offending device. For example, connecting the RP2040 to port 1 of a 7 port hub, and connecting the USB serial console to port 7, may solve the issue. Connecting the RP2040 to a separate USB hub to any busy devices will also fix the problem.

Workaround

Use software to force USB device controller to see idle USB bus for 800µs to move the device from the RESET state to the CONNECTED state. This fix uses internal debug logic that is connected to GPIO15 for a short amount of time (~800µs). This forces the controller to see DP as a logical 1 (and DM as logical 0) to make the USB Device controller believe there is a J-state on the USB bus. GPIO15 does not need to be tied in any particular way for this fix to work. Instead, we can force the input path in software using the Section 2.19 input override feature. See https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c .

NOTE The workaround takes control of GPIO 15 during a device reset, so you need to be sure that you are not using GPIO 15 for anything else during a device reset before using the workaround. A device reset happens after the first connection, but may also happen at other times under the host's control.

Using the workaround with TinyUSB and the SDK is easy, as the above source file is included by the library pico_fix_rp2040_usb_device_enumeration (which is automatically added as a dependency of TinyUSB in device mode). The fix itself is still off by default though, since the fix's use of GPIO 15 may conflict with the application's own use of GPIO 15. You can enable it by setting either PICO_RP2040_USB_DEVICE_ENUMERATION_FIX=1 as part of your compiler definitions in your CMakeLists.txt , or TUD_OPT_RP2040_USB_DEVICE_ENUMERATION_FIX=1 in your tusb_config.h .

It is safe (and inexpensive) to enable the software workaround even when using versions of RP2040 which include the fix in hardware.

AffectsRP2040B0, RP2040B1
Fixed byRP2040B2. Software workaround on RP2040B0, RP2040B1. The workaround isn't present in the USB mass storage code in the bootrom. The software workaround requires use of GPIO15 during USB bus reset.

RP2040-E15

ReferenceRP2040-E15
SummaryUSB Device controller will hang if certain bus errors occur during an IN transfer.
Description

The USB Device controller enters an unrecoverable state if the following critical sequence of events occurs:

  • • RP2040 is connected to a VL805 xHCI controller and is operating in full-speed mode
  • • The integrated hub detects an impending line collision between downstream port Transaction Translator traffic and broadcast upstream traffic (Start-of-Frame token)
  • • The integrated hub forces a bitstuffing error during the PID or CRC portions of the downstream in-progress packet or token.

This sequence is known to occur with the downstream-facing ports on a Raspberry Pi 4 or a Raspberry Pi 400 and Bulk IN endpoints with data buffer sizes of more than 50 bytes. In this case, the integrated USB2.0 hub incorrectly determines the remaining full-speed frame time in anticipation of a SOF packet from the host, and erroneously transmits an IN token which results in the later ACK reply being corrupted and replaced by the propagated SOF packet.

This type of data corruption is not properly handled by the device state machine, and the device controller must be reset.

This sequence has not been seen to occur on commodity USB2.0 hubs, nor on Root Ports that are not provided by a VL805 xHCI controller.

Workarounds

1) VL805 firmware version 0138c1

An updated firmware has been pushed to the DEFAULT channel in the raspberrypi-bootloader Apt package on Pi 4 products. This corrects the erroneous hub time calculation. This firmware update is not automatically applied, users must run sudo rpi-eeeprom-update -a on the Pi 4 and follow on-screen instructions.

2) Linux Kernel xHCI driver patch

A kernel update is available for the Raspberry Pi 4-series products that, for VL805 firmware versions earlier than 0138c1, avoids enqueueing single Transfer Descriptors to the controller for affected endpoints during the last microframe of a full-speed frame. This update is available in the raspberrypi-kernel Apt package.

2) SDK v1.5.0 / TinyUSB 0.15.0

TinyUSB starting at version 0.15.0 adds a workaround for this erratum, and this version is picked up in the v1.5.0 release of the SDK. The dcd_rp2040 driver will avoid enabling bulk IN buffers during the last 200µs of a full-speed frame. This reduces available Bulk IN bandwidth by approximately 20%, and selectively enables the Start-of-Frame interrupt.

The TinyUSB workaround is not necessary for implementations that will never be connected to a vulnerable VL805 port, for example in a circuit design where RP2040 is directly connected to an on-board hub. The workaround can be disabled by defining TUD_OPT_RP2040_USB_DEVICE_UFRAME_FIX=0 in your tusb_config.h .

AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byDocumentation, Software

RP2040-E16

ReferenceRP2040-E16
SummaryInadequate synchronisation of USB status signals
Description

Within the USB peripheral, certain Host and Device controller events cross from clk_usb to clk_sys . Many of these signals do not have appropriate synchronisation methods to ensure that they are correctly registered when clk_sys is equal to or slower than clk_usb .

The following signals lack appropriate synchronisation methods:

SIE_STATUS :

* TRANS_COMPLETE * SETUP_REC * STALL_REC * NAK_REC * RX_SHORT_PACKET * ACK_REQ * DATA_SEQ_ERROR * RX_OVERFLOW

INTR :

* HOST_SOF * ERROR_CRC * ERROR_BIT_STUFF * ERROR_RX_OVERFLOW * ERROR_RX_TIMEOUT * ERROR_DATA_SEQ

The bootrom's USB bootloader chains clk_sys from clk_usb , therefore the two clock frequencies are identical and have a fixed phase relationship. In this condition and at extremes of PVT, lab testing has observed that these events may be lost, which results in unreliable USB bootloader behaviour.

WorkaroundRun clk_sys faster than clk_usb by at least 10% when the peripheral is in use. Signalling of quasi-static bus states such as reset, suspend, and resume are not affected by this erratum, so clk_sys can be lower in these cases.
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byDocumentation, software. Not fixed in the RP2040 bootrom.

Watchdog

RP2040-E1

ReferenceRP2040-E1
SummaryWatchdog count is decremented twice per tick.
DescriptionThe watchdog ( Section 4.7 ) has a 24-bit counter, that decrements every tick, starting from a user defined value set in LOAD register. There is a logic error which means the counter is decremented twice per tick, instead of once per tick. In a recommended setup where the tick occurs at 1µs intervals, this halves the maximum time between resetting the watchdog counter from ~16.7 seconds to ~8.3 seconds.
WorkaroundUse double the desired value in LOAD .
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byDocumentation, Software

XIP Flash

RP2040-E8

ReferenceRP2040-E8
SummaryRace condition when aborting an XIP DMA stream and immediately starting a new stream
Description

The XIP DMA streaming hardware allows a linear sequences of flash reads to proceed in the background, and be read by the DMA, without subjecting the DMA to the bus stalls caused by a normal XIP-window access. A stream is begun by writing to the STREAM_ADDR register, followed by STREAM_CTR , and can be aborted midway by writing 0 to STREAM_CTR .

When a stream is aborted in this way, there is sufficient time for software to load a new address and begin a new stream whilst the final SPI/QSPI access of the aborted stream is still in progress. This causes the newly-loaded stream address to be incremented once before the first data transfer of the new stream sequence, so the entire stream takes place at a 4-byte offset.

WorkaroundAfter clearing STREAM_CTR , immediately perform one dummy read from the uncached XIP window, e.g. (void)*(io_ro_32*)XIP_NOCACHE_NOALLOC_BASE; . If an XIP stream transfer is still in progress, this dummy read will stall until that transfer completes. It is then safe to begin a new stream by writing to STREAM_ADDR followed by STREAM_CTR .
AffectsRP2040B0, RP2040B1, RP2040B2
Fixed byDocumentation, Software

Appendix C: Availability

Raspberry Pi understands the value to customers of long term availability of product and therefore aims to continue supply for as long as practically possible. We expect RP2040 to remain in production until at least January 2041.

Support

For support see the Pico section of the Raspberry Pi website , and post questions on the Raspberry Pi forum .

Ordering code

RP2040 can be ordered in bulk from Raspberry Pi Direct .

Table 638. Part Number

ModelOrder CodeMinimal Order QuantityRRPEquivalent price per chip
7" reel of 500 × RP2040 chipsSC0914(7)1+ pcs / BulkUS$400.00US$0.80
13" reel of 3,400 × RP2040 chipsSC0914(13)1+ pcs / BulkUS$2,380.00US$0.70

NOTE

RRP was correct at time of publication and excludes taxes.

Documentation Release History

20 February 2025

15 October 2024

02 May 2024

02 February 2024

14 June 2023

03 March 2023

01 December 2022

30 June 2022

17 June 2022

04 November 2021

03 November 2021

30 September 2021

23 June 2021

07 June 2021

13 April 2021

07 April 2021

05 March 2021

23 February 2021

01 February 2021

26 January 2021

21 January 2021

Raspberry Pi logo

The Raspberry Pi logo, which is a stylized white raspberry fruit with a small green leaf on top, set against a dark red background.

Raspberry Pi logo

Raspberry Pi

Raspberry Pi is a trademark of Raspberry Pi Ltd