You save the prototype's program as main.py so it starts without a laptop. After the next power cycle, the board keeps restarting and your editor cannot stay connected. If that board also holds the only copy of a script, calibration settings or trial data, recovery is now more than a matter of reinstalling firmware.
Our recovery notes for MicroPython boards distinguish two kinds of tool: one erases flash, and another was created to rename a troublesome startup file. That distinction matters for a small team preparing prototypes for other people. Start by identifying what you can still access and what you need to preserve. A filename ending in .uf2 does not tell you whether the contents of the board will survive.
A recent example shows why the symptoms need separating. In a September 2026 DigiKey TechForum post, a Pico user reported intermittent serial access and difficulty getting the BOOTSEL drive to appear after running a loop and attempting recovery. Replies suggested connection and button-sequence checks, but the thread did not confirm a fix. It is a current example of the problem, not proof that a watchdog caused it.
First distinguish a running program from an inaccessible board
When the normal USB serial connection is available, try interrupting the application and reaching the interactive prompt, the REPL. MicroPython commonly lets Ctrl-C interrupt Python code. If you regain access, copy the files you need to the computer before changing the startup file. Put them in a new folder so an older backup is not overwritten.
A reachable prompt is different from BOOTSEL mode. The prompt lets you work with MicroPython and its files; BOOTSEL is a firmware-loading route. The bootloader's USB drive is not the Python filesystem, and you cannot drag a main.py file out of it. MicroPython's reset and boot documentation explains the startup-file and REPL behavior.
There is a further complication once a hardware watchdog has started: stopping Python does not necessarily stop the reset countdown. The MicroPython 1.23 WDT reference states that an enabled watchdog cannot be stopped or reconfigured. A brief connection followed by another reset needs a different diagnosis from an editor simply waiting on a long-running Python loop.
If the prompt is stable, preserve the startup file
After making a computer-side backup, rename the suspect startup file to an unused name rather than deleting it. Confirm that the destination name does not already exist. The aim is to stop that file being picked automatically on the next normal startup while keeping it available for inspection.
Also inspect boot.py if it is present. It runs earlier in startup, so disabling main.py cannot fix every startup failure. Likewise, reflashing the same interpreter may leave the Python filesystem intact and bring back the same troublesome script. Keep a record of the last code change and the firmware version; repeated reflashing otherwise hides what changed.
What the community rename tool was designed to do
In February 2021, Raspberry Pi forum contributor hippy shared MicroPython_RenameMainDotPy.uf2, a special MicroPython-derived image intended to rename main.py while leaving the rest of the internal filesystem alone. The author's forum post describes a repeated five-flash LED indication and reinstalling MicroPython afterward.
This is a community recovery tool with a specific history, not a universal rescue image for every Pico-family board. Before considering it, establish the board, flash arrangement and MicroPython filesystem it was built for. Finding a copy in a local folder of firmware files does not establish where it came from or what it is compatible with.
We have not verified that old binary against a current board or firmware build, and we have no before-and-after recovery run with it. Treat it as a lead to an attributed tool, not a guarantee that valuable files can be recovered. If those files are irreplaceable and the prompt is inaccessible, preserve the board's current state while the recovery approach is checked.
Understand what a full erase changes
The other common file, flash_nuke.uf2, erases flash. Raspberry Pi's example source code erases the flash range it determines for the build and device, then returns to the USB bootloader. On a normal Pico MicroPython installation, that removes the interpreter and its internal filesystem, including startup scripts and locally stored data.
You will sometimes read that neither recovery file can clear boot.py. That is misleading. A targeted main.py rename leaves a separate boot.py alone; erasing the flash that holds the filesystem removes both. These are different operations with different consequences.
| Tool | What it changes | What survives |
|---|---|---|
| Rename image | main.py is renamed |
Other files, including boot.py |
| Flash erase | Interpreter and filesystem are erased | Nothing on the board |
| Reflash same firmware | Interpreter is reinstalled | Usually the filesystem, including the faulty script |
A full erase can be a reasonable rebuild step when the necessary files are backed up and the correct firmware and application are at hand. It is not a way to retrieve files that were never copied elsewhere. Decide which situation you are in before choosing a recovery image, and use the documented image for the exact board.
Make the next prototype easier to maintain
Once access is restored, fix the startup behavior before reinstalling the application. Keep a known working copy on the computer, document firmware and library versions, and test the program interactively before making it start automatically. Give whoever maintains the prototype a defined way to enter a maintenance state before the application enables its watchdog.
For a prototype with a watchdog, test two separate outcomes: whether a genuine failure triggers recovery, and whether the team can still service the device afterward. A reset that immediately repeats the same fault is not a successful recovery from the user's point of view. A short startup delay can give bench access, but it does not replace testing the maintenance path on the actual firmware.
Finally, rehearse the handover: disconnect the development tools, power the device the way its user will, and follow your own recovery instructions. Record what stays accessible and whether settings and data survive the chosen procedure. These are the acceptance checks we recommend; this note does not report a recovery run.