In theory, it’s close to impossible to brick your Raspberry Pi Pico 2 or other RP2350 boards because the bootrom code (source code) is stored in the 32KB ROM of the microcontroller and is by definition “read-only memory”. But I managed to “brick” my Raspberry Pi Pico 2 the other day, and even a blinky sample would not run on the board. So I’ll explain a simple method to recover/perform a factory reset of sorts.
First, let me explain what happened. My board became unusable after I ran the following command while building RISC-V Linux for RP2035 and my Pico 2 was connected to the build machine:
1 |
make flash-kernel |
At some point, it will copy a UF2 firmware binary designed for boards with PSRAM which the Raspberry Pi Pico 2 lacks:
1 |
cp build/psram-bootloader.uf2 "/media/jaufranc/RP2350"/ |
After that, I could still see the Raspberry Pi Pico 2 board as an “RP2350” drive on my computer, and you could copy another UF2 file like the blink_simple.uf2, but nothing would happen. Connecting a serial console showed the following:
1 2 3 |
Invalid PSRAM ID: 0 PSRAM setup failed Press any key to reset. |
So it’s clear the old firmware expecting PSRAM was still running, and copying various UF2 (blink_simple, CircuitPython…) files changed nothing.
The solution to a bricked Raspberry Pi Pico 2 / RP2350 board is to simply download and copy flash_nuke.uf2 (it’s the same file for RP2040 and RP2350) to the RP2350 drive on your computer and it will automatically erase the flash and recover the board. That’s it.
What apparently happened is that the RISC-V Linux firmware creates partitions on the board, and those are not wiped out when copying a new UF2 file with the program running from flash. But the flash_nuke program runs once from RAM and is not impacted. You’ll find the source code @ https://github.com/raspberrypi/pico-examples/blob/master/flash/nuke/, and the following line in CMakeLists.txt forces it to run from RAM:
1 |
pico_set_binary_type(flash_nuke no_flash) |
I got the solution via the comments section on CNX Software and the Raspberry Pi forums where you’ll find more details about what actually happens under the hood.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
A very similar “flash_nude” approach was needed for Meshtastic NRF52 devices to clear the User_Data area (littlefs volume) used to store Meshtastic configuration files – https://cdn-learn.adafruit.com/assets/assets/000/065/418/original/microcontrollers_S132_and_S140_v6.png?1541757141