The Raspberry Pi Pico 2 (based on the RP2350 chip) maintains the exact same 40-pin physical DIP footprint as the original Pico 1, but the internal architecture, power delivery, and peripheral routing have shifted. If you are migrating a design or building a new harness, you need the exact RP2350 board-level mappings, not the raw silicon datasheet. Below is the complete board-level pinout, followed by the wiring standards and decision paths you need to terminate your design.
The Complete Raspberry Pi Pico 2 (RP2350) Pinout Table
This table reflects the physical pins broken out on the Pico 2 board. While the RP2350 silicon features 48 internal GPIOs, the board strictly limits physical access to 26 multi-function GPIOs to preserve backward compatibility with Pico 1 shields and breadboard layouts.
| Pin # | Silkscreen Name | Primary Function | Alternate / RP2350 Specific Notes |
|---|---|---|---|
| 1 | GP0 | GPIO / UART0 TX | SPI0 RX, I2C0 SDA, PWM0 A |
| 2 | GP1 | GPIO / UART0 RX | SPI0 CSn, I2C0 SCL, PWM0 B |
| 3 | GND | Ground | Common return path |
| 4 | GP2 | GPIO | SPI0 SCK, I2C1 SDA, PWM1 A |
| 5 | GP3 | GPIO | SPI0 TX, I2C1 SCL, PWM1 B |
| 6 | GP4 | GPIO / I2C0 SDA | SPI0 RX, PWM2 A |
| 7 | GP5 | GPIO / I2C0 SCL | SPI0 CSn, PWM2 B |
| 8 | GND | Ground | Common return path |
| 9 | GP6 | GPIO | SPI0 SCK, I2C1 SDA, PWM3 A |
| 10 | GP7 | GPIO | SPI0 TX, I2C1 SCL, PWM3 B |
| 11 | GP8 | GPIO | SPI1 RX, I2C0 SDA, PWM4 A |
| 12 | GP9 | GPIO | SPI1 CSn, I2C0 SCL, PWM4 B |
| 13 | GND | Ground | Common return path |
| 14 | GP10 | GPIO | SPI1 SCK, I2C1 SDA, PWM5 A |
| 15 | GP11 | GPIO | SPI1 TX, I2C1 SCL, PWM5 B |
| 16 | GP12 | GPIO | SPI1 RX, I2C0 SDA, PWM6 A |
| 17 | GP13 | GPIO | SPI1 CSn, I2C0 SCL, PWM6 B |
| 18 | GND | Ground | Common return path |
| 19 | GP14 | GPIO | SPI1 SCK, I2C1 SDA, PWM7 A |
| 20 | GP15 | GPIO | SPI1 TX, I2C1 SCL, PWM7 B |
| 21 | GP16 | GPIO / SPI0 RX | I2C0 SDA, PWM0 A (Default SPI) |
| 22 | GP17 | GPIO / SPI0 CSn | I2C0 SCL, PWM0 B |
| 23 | GND | Ground | Common return path |
| 24 | GP18 | GPIO / SPI0 SCK | I2C1 SDA, PWM1 A |
| 25 | GP19 | GPIO / SPI0 TX | I2C1 SCL, PWM1 B |
| 26 | GP20 | GPIO | SPI0 RX, I2C0 SDA, PWM2 A |
| 27 | GP21 | GPIO | SPI0 CSn, I2C0 SCL, PWM2 B |
| 28 | GND | Ground | Common return path |
| 29 | GP22 | GPIO | SPI0 SCK, I2C1 SDA, PWM3 A |
| 30 | RUN | Reset / Enable | Pull low to reset the RP2350 |
| 31 | GP26 / ADC0 | GPIO / Analog In | SPI1 SCK, I2C1 SDA, PWM5 A |
| 32 | GP27 / ADC1 | GPIO / Analog In | SPI1 TX, I2C1 SCL, PWM5 B |
| 33 | AGND | Analog Ground | Reference for ADC measurements |
| 34 | GP28 / ADC2 | GPIO / Analog In | SPI1 RX, I2C0 SDA, PWM6 A |
| 35 | ADC_VREF | ADC Voltage Ref | Defaults to 3.3V; cut trace for precision |
| 36 | 3V3 | 3.3V Output | Max draw ~300mA (via onboard SMPS) |
| 37 | 3V3_EN | SMPS Enable | Pull low to disable 3.3V rail |
| 38 | GND | Ground | Common return path |
| 39 | VSYS | System Voltage | Input (1.8-5.5V) or Output to peripherals |
| 40 | VBUS | USB Voltage | 5V from USB connector (fused) |
Decoding Symbols, Power Rails, and Regional Wire Colors
When building wiring harnesses for the Pico 2, you must translate the board's silkscreen symbols into physical wire colors. Because maker projects cross borders, we map the Pico's power and signal rails to both IEC 60446 (International/European) and NEC/US conventions for DC low-voltage wiring.
- VBUS / VSYS (DC+): Use Brown (IEC) or Red (US). Note: VBUS is strictly 5V from USB. VSYS is the main system rail (1.8V to 5.5V).
- GND / AGND (DC-): Use Blue (IEC) or Black (US). Always tie AGND and GND together at a single star-point if you are mixing digital and high-current analog loads.
- I2C / SPI Signals: Use Yellow or Orange universally to denote active data lines.
- 3V3 Output: Use Orange (IEC) or Yellow (US) to distinguish it from the main 5V VBUS feed.
The RP2350 introduces a switched-mode power supply (SMPS) replacing the linear LDO found on the Pico 1. This means the 3V3 pin can safely supply closer to 300mA-400mA without the board overheating, compared to the Pico 1's ~150mA safe limit. However, the 3V3_EN pin now controls the SMPS enable line rather than a simple LDO shutdown.
The 'Rows People Get Wrong' Trap
Even experienced embedded engineers make three specific mistakes when migrating from other microcontrollers (like STM32 or ESP32) to the Raspberry Pi Pico 2. Review the official RP2350 Datasheet for the deep silicon specs, but heed these board-level hardware traps:
1. The 5V Tolerance Myth
The RP2350 GPIOs are strictly 3.3V tolerant. Unlike the 5V-tolerant pins on many STM32F4 boards, feeding a 5V logic signal into GP0-GP28 will permanently damage the silicon pad. If you are interfacing with 5V sensors (like the HC-SR04 ultrasonic module or legacy 5V I2C displays), you must use a bidirectional logic level shifter (e.g., TXB0108 or a simple MOSFET-based BSS138 breakout) or a voltage divider.
2. ADC_VREF vs 3V3 Noise
On the Pico 2 board, the ADC_VREF pin (Pin 35) is internally tied to the 3V3 SMPS output via a ferrite bead. While this works for basic potentiometer readings, the SMPS switching noise will ruin precision analog measurements (like load cells or thermistors). The fix: Use a craft knife to carefully cut the tiny copper trace on the back of the board connecting ADC_VREF to 3V3, then feed Pin 35 with a clean, external 3.0V or 3.3V voltage reference IC (like the LM4040).
3. SWD Debugging Pin Confusion
The RP2350 silicon uses GP23, GP24, and GP25 for internal boot and flash communication. However, on the physical Pico 2 board, these are not broken out on the main 40-pin header. To attach a Picoprobe or SWD debugger, you must use the dedicated 3-pin debug header located near the USB-C port (SWDIO, GND, SWCLK).
Faded Silkscreen? How to Safely Verify Pins
After months of breadboarding, the white silkscreen on the black PCB often wears off. Guessing pin locations based on memory leads to shorting VBUS to a GPIO, instantly bricking the RP2350. If your markings are missing, follow this safe verification protocol:
- Locate Pin 1: Turn the board over. With the USB-C port facing 'up' (away from you), the bottom-left pad on the rear side is slightly more square than the others. This is physically hard-coded as Pin 1 (GP0).
- Verify Ground: Set your multimeter to continuity mode. Probe the USB-C port's outer metal shield. Any pin that beeps continuously with the shield is a GND pin. (The Pico 2 has 8 GND pins across the header).
- Verify VBUS: Plug the board into a USB data blocker (power only). Set the meter to DC Voltage. Probe the top-right pin (Pin 40). It should read between 4.75V and 5.25V. If it reads 0V, your USB cable is charge-only or the onboard polyfuse has tripped.
- Verify RUN: Pin 30 is the RUN pin. With the board powered, briefly touching this pin to a verified GND pin will cause the RP2350 to instantly reset and remount its USB drive.
Decision Tree: Which Pin Should You Actually Use?
The RP2350 allows almost any GPIO to be mapped to any peripheral via the PIO (Programmable I/O) or internal muxing. However, relying on default hardware mappings saves flash space and reduces latency. Use this decision table to terminate your pin selection process with a concrete pick.
| Your Use Case | Condition / Constraint | Concrete Pin Pick (Default) |
|---|---|---|
| Standard I2C Sensor (BME280, OLED) | Need default hardware I2C0 bus | GP4 (SDA) & GP5 (SCL) |
| High-Speed SPI Display (ILI9341) | Need default hardware SPI0 bus | GP16 (RX), GP17 (CS), GP18 (SCK), GP19 (TX) |
| UART GPS Module (NEO-6M) | Need default hardware UART0 | GP0 (TX) & GP1 (RX) |
| Analog Voltage Reading | Need 12-bit ADC, single channel | GP26 (ADC0) |
| Driving a 5V Relay Module | Need 5V logic output (Optocoupler) | VBUS (via NPN transistor driven by GP2) |
| Deep Sleep / Battery Power | Need to cut all quiescent draw | Drive 3V3_EN low via an external RTC interrupt |
For a complete breakdown of the Pico series hardware architecture and C/C++ SDK mappings, always cross-reference your physical wiring with the official Raspberry Pi Pico Documentation. Stick to the concrete picks above for your first prototype to ensure native hardware peripheral support without writing custom PIO state machines.






