Have I lost my code? :-)

[mc-mc]

I have a Pico W and a few months ago wrote some code that reads from a one wire temp sensor, connects to the internet, posts the result to an iotplotter.com feed, sleeps and repeats. It took a few hours to get this working. I put the code in main.py so it would run at startup and I think the last thing I did was add a global exception handler which will do a restart if it gets an exception. It's been running for months, but every few days it stops working and I have to re-power it when it will again work for a few more days.

Stupidly (in hindsight) the only copy of the code is on the pico itself. I didn't save a copy to my PC.

Today I've tried to make some changes to it. Unfortunately when I now connect the pico to the PC it starts executing my code and I can't get a REPL or Thonny connection. I see my debug print statements being written to the console (COM3) and pressing ctrl-c or ctrl-d I can see my exception handler message and the code restarts. Pressing the stop/restart button in Thonny just restarts my lovely uninterruptable code. Thonny just reports "Device is busy" and offers the ctrl-c or press stop / restart advice.

I realise I can probably hold down the bootsel button and reflash the micropython installation with a clean copy and get the device back to normal, but this presumably will lose my code.

I've tried using rshell but that just says waiting for REPL and has the same issue as Thonny.

Is there anyway I can get my code back? Or will I just have to learn my lesson and re-write it again without the aggressive exception handler this time. :-)

Ideally I just want to rename the main.py file to something else before the code is able to start.

Any advice is welcome!

[bixb922]

Try with mpremote. You should be able to enter REPL with a control C or do mpremote cp :main.py my_copy_of_main.py. For me, it always has been able to get control back.

[mc-mc]

Try with mpremote. You should be able to enter REPL with a control C or do mpremote cp :main.py my_copy_of_main.py. For me, it always has been able to get control back.

Thanks for the suggestion, I didn't know about mpremote.. Sadly doesn't seem to work in this case. a "mpremote c3" shows messages from my script and mpremote trying to reboot it get control (my exception handler repeatedly gets fired).

Eventually I get the error: mpremote.pyboard.PyboardError: could not enter raw repl

Trying to issue mpremote commands on the command line I get the same issue.

[bixb922]

That's unexpected. What happens if you use putty and do a control C?

[mc-mc]

same thing, ctrl-c is caught by my exception handler which outputs a message and restarts the code.
Same with ctrl-d.

I'd show you what I coded but that's the problem I don't have the code. :-)

Upside is I've learnt a lot about rshell, mpremote and how things work, trying to fix this.

[scruss]

This thread from the Raspberry Pi Forum might help: Recovering files from a Pico file system - Raspberry Pi Forums. You want to look for the entries that contain a link to 'dumplfs'.

[mc-mc]

Success! Was able to dump my pico's flash memory using the command "picotool save -a pidump.bin". Using a hex editor I was able to search the pidump file for my Wifi SSID and find my code which fortunately was still in plaintext. In fact I was able to find lots of versions of my code at different stages of development. I presume every time I saved my file it was doing some sort of wear levelling of the flash and saving it in a different location meaning there were multiple copies for me to find and recover. In fact the code was easy to find as it was all at the end of the 2Mb dump file.

This is what I had in main.py:

while True:
try:
logic()
except:
print("Error exception")

Where logic() was the function containing all my main code. So don't do that!

Many thanks to all that tried to help me out!

[mc-mc]

The dumplfs script worked too! Extracted the file system from my extracted bin file to my PC. Now safely stored in Dropbox.

[robert-hh]

In the same scenario I made once a firmware which renamed main.py during boot. I can create one for Pico W if you like.

[mc-mc]

Fortunately no need as I was able to dump the flash and extract the code. Many thanks for the offer though.

[robert-hh]

It's here: https://github.com/robert-hh/Shared-Stuff/blob/master/firmware_rp2_W_main_rename.uf2

[mc-mc]

Oh you went ahead anyway. :-) Since I have the code secure now. I'm going to give it a try...

and... it worked! I have the Pico responding again and have a main_saved.py on there!

Many thanks!

[picpic020960]

Bonjour
Maybe with dowlloaded memory in rpi Pico simulator?
(or with partition tools like esptool (Esp32) but harder}
https://wokwi.com/projects/new/pi-pico

[mc-mc]

Oh wow there's a web based Pico simulator, yet another thing I've learnt about. Cheers!

[peterhinch]

A hint for future projects. Have a main.py that looks like this:

time.sleep(4)
import my_application

The sleep ensures that even if the application completely locks up the machine, you can always reboot and issue ctrl-c.

[mc-mc]

Yes certainly I'll be more careful in future. I'm thinking I'll check for a pin being grounded at start up and in the exception handler and that will act as a debug flag to exit the code loop . and not retry.

Cheers for the advice.

[mc-mc]

In fact the sleep before I enter my main processing loop works very well. I just have to restart the pico and connect Thonny whilst it's sleeping and it's able to get control back. One the main loop starts I'm back to my interruptible code. :-)
Looks like handling the KeyboardInterrupt exception will fix the problem for good.

print("Sleeping for a bit to allow interrupt")
time.sleep(4)
print("Carry on with the code...")
    
while True:   
    try:
        Logic()
    except KeyboardInterrupt:
        print("Ctrl-C pressed, exiting...")
        sys.exit()
    except:
        print("Caught error exception...")

[peterhinch]

I would still advocate the time.sleep in main.py or your (faster) suggestion of checking a pin. This is because there are rare situations in which a program can lock up solid and not respond to ctrl-c - mainly if you use external hardware or write C code, or if you encounter a MP bug.

It's also worth noting that an except clause traps everything including coding errors...

[mc-mc]

Yes that's what I have now, the sleep at the start works nicely. and so does not catching and ignoring ctrl-c :-)