hippy
Posts: 16116
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Bricked MicroPython rescue firmware

Fri Feb 26, 2021 4:05 pm

If you 'brick MicroPython' on your Pico by creating a 'main.py' which prevents the REPL from being entered, prevents Thonny and other tools from accessing the Pico; this firmware should rescue you from that situation by renaming 'main.py' to something else; probably 'main-1.py' for most people.

When the 'MicroPython_RenameMainDotPy.uf2' image is flashed to your Pico and it has done its thing, its on-board LED will repeatedly flash five times. MicroPython can then be reflashed and everything should work again - Except 'main.py' won't be there to be executed and brick things again.

Flashing this firmware can be preferable to using 'flash_nuke.uf2' because it only affects 'main.py', leaves the MicroPython internal file system otherwise unaffected.

If you access the Pico through Thonny while the 'MicroPython_RenameMainDotPy' firmware is flashed, pressing Ctrl-D will have it report what it did, what it renamed 'main.py' to.

Acknowledgements and Copyright

"MicroPython_RenameMainDotPy" is derived from MicroPython, Copyright (c) 2013-2021 Damien P. George.
https://github.com/micropython/micropython

Download ...
MicroPython_RenameMainDotPy.uf2.zip
(182.54 KiB) Downloaded 7589 times

hippy
Posts: 16116
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Bricked MicroPython rescue firmware

Fri Feb 26, 2021 4:38 pm

Source Code ...
MicroPython_RenameMainDotPy.source.zip
(12.04 KiB) Downloaded 933 times

Code: Select all

pi@Pi3B:/tmp $ ls -l *.zip
-rw-r--r-- 1 pi pi  12329 Feb 26 16:28 MicroPython_RenameMainDotPy.source.zip

Code: Select all

pi@Pi3B:/tmp $ unzip -l MicroPython_RenameMainDotPy.source.zip 
Archive:  MicroPython_RenameMainDotPy.source.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2021-02-26 16:26   ports/rp2_MicroPython_RenameMainDotPy/
     7135  2021-02-26 16:23   ports/rp2_MicroPython_RenameMainDotPy/main.c
        0  2021-02-26 16:24   ports/rp2_MicroPython_RenameMainDotPy/modules/
      945  2021-02-26 16:23   ports/rp2_MicroPython_RenameMainDotPy/modules/_rescue.py
    24363  2021-02-26 16:23   ports/rp2_MicroPython_RenameMainDotPy/pyexec.c
     4611  2021-02-26 16:23   ports/rp2_MicroPython_RenameMainDotPy/CMakeLists.txt
---------                     -------
    37054                     6 files
Building

Clone the MicroPython 'rp2' port as 'rp2_MicroPython_RenameMainDotPy", then overlay the extracted source over the top. Build as usual.

User avatar
scruss
Posts: 5825
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON

Re: Bricked MicroPython rescue firmware

Fri Feb 26, 2021 5:39 pm

hippy wrote:
Fri Feb 26, 2021 4:05 pm
If you 'brick MicroPython' on your Pico by creating a 'main.py' which prevents the REPL from being entered …
I'm glad I've only ever had to hit the "Stop" button in Thonny to get the REPL back.

So does this create a boot.py that renames the existing main.py and exits?
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him

konstructorAzul
Posts: 1
Joined: Fri Feb 26, 2021 6:43 pm

Re: Bricked MicroPython rescue firmware

Fri Feb 26, 2021 6:53 pm

I dont have a main.py. I can flash everything with no errors. I have the 5 blinks repeating. Thonny gives gray bars in the shell output. When I try to open a file from the rpi pico, it throws the error: cant complete: device is busy -- cant perform this action now. please wait or cancel current work and try again! I dont want to nuke it because I have a bunch of untransfered files.

papous
Posts: 81
Joined: Fri Jan 05, 2018 5:50 am

Re: Bricked MicroPython rescue firmware

Sat Feb 27, 2021 9:54 am

Can we have some more details on this for the uninitiated?
will it unbrick ESP32?

fivdi
Posts: 584
Joined: Sun Sep 23, 2012 8:09 pm

Re: Bricked MicroPython rescue firmware

Sat Feb 27, 2021 11:11 am

hippy wrote:
Fri Feb 26, 2021 4:05 pm
If you 'brick MicroPython' on your Pico by creating a 'main.py' which prevents the REPL from being entered, prevents Thonny and other tools from accessing the Pico;

In general, creating a 'main.py' won't prevent access to the REPL and hitting ctrl+c will typically be enough to interrupt main.py and enter the REPL.

Running the following two rshell commands from the command line is likely to be all that's needed to rename main.py to main-1.py in many cases:

Code: Select all

rshell --quiet --port /dev/ttyACM0 cp /pyboard/main.py /pyboard/main-1.py
rshell --quiet --port /dev/ttyACM0 rm /pyboard/main.py
https://github.com/fivdi

hippy
Posts: 16116
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Bricked MicroPython rescue firmware

Sat Feb 27, 2021 12:37 pm

fivdi wrote:
Sat Feb 27, 2021 11:11 am
In general, creating a 'main.py' won't prevent access to the REPL and hitting ctrl+c will typically be enough to interrupt main.py and enter the REPL.
Agreed. This is mostly needed for those who have put something in 'main.py' which causes Ctrl-C not to work. I have done that when using 'micropython.kbd.intr(-1)' so I could read raw 8-bit characters from the host over USB, also viewtopic.php?f=146&t=305399 and I recall a couple of others have hit similar problems.

The problem is, once Ctrl-C is blocked, the REPL can't be entered and Thonny, rshell, ampy all rely on being able to get to the REPL to allow interaction with the file system. There's no way to get into the Pico to delete 'main.py' or do anything else to prevent it blocking REPL on every power-up. There's nothing more which can be done beyond re-flashing another .uf2

And that .uf2 has had to have been 'flash_nuke.uf2' because most other things won't wipe the MicroPython internal file system so it remains intact, along with the problematic 'main.py' once MicroPython has been flashed again.

Nuking isn't desirable because that loses everything in flash, including files which have not been backed-up on the host, requiring needed files to be re-loaded again. This is the answer to; who will rid me of this troublesome 'main.py' ?

Blocking Ctrl-C will most times be a simple rookie mistake when unfamiliar with the consequences it has with no thought to avoiding those. The realisation that the Pico is 'bricked' only occurs after having done it. And it's not exactly clear how to recover from that. Efforts to reflash MicroPython and other .uf2 are found to be fruitless leaving only nuking. This provides a better route out of that situation.

I have been following the No Button Boot (NBB) threads and it looks possible to incorporate a means of recovery, forcing 'main.py' renaming, within MicroPython even if Ctrl-C is blocked without introducing adverse effects. This utility firmware would still be needed for people not using such a modified MicroPython.

hippy
Posts: 16116
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Bricked MicroPython rescue firmware

Sat Feb 27, 2021 12:51 pm

papous wrote:
Sat Feb 27, 2021 9:54 am
Can we have some more details on this for the uninitiated?
Not sure what more details are needed. It's a hacked MicroPython build which runs "_rescue.py" rather than "main.py" at start-up which renames "main.py" so that no longer runs when MicroPython is re-flashed and re-boots.
papous wrote:
Sat Feb 27, 2021 9:54 am
will it unbrick ESP32?
Possibly, if it's 'main.py' or its presence which is bricking things.

Edit line 122 in 'ports/esp32/main.c' to be "_rescue.py" rather than "main.py" and drop "_rescue.py" into the "ports/esp32/modules" sub-directory. All the rest of my changes were cosmetic and niceties.

You will need to remove Pico specific code from my "_rescue.py". That should work but I have never built MicroPython for ESP32 so can't promise it will.

luisdaniel.ta
Posts: 1
Joined: Sat Jun 12, 2021 8:49 pm

Re: Bricked MicroPython rescue firmware

Sat Jun 12, 2021 8:51 pm

thank you very much, you saved my life

Return to “MicroPython”