RP2040 REPL unreliability

[MoffKalast]

Specifically the issue where the RP2040 can be soft bricked relatively easily by running it with a main.py that either does not compile or crashes in some way. It's especially problematic because it's a pitfall nearly every user will fall into, trying to test if their code runs at boot or not.

By now it's been well documented and it's so prevalent that some good samaritans have even made a "nuker" firmware set that deletes only the user files in order to get out of the soft brick state, and one that just deletes the main.py so you can work around the issue by just importing your actual main in it iirc. Talk about extensive impractical workarounds.

The interesting thing is though, I've always ran micropython on ESP32s, where strangely enough this straight up does not happen. I've used it on WROOMS, WROVERS, single, multicores, whatever, I never managed to get any of them to fully hang while running serial through a cable, and I've been pretty careless by anyone's standards at times. The Ctrl+C signal always manages to get through eventually.

From where I'm standing it seems there's either a hardware problem or an implementational problem. Does the Pi handle serial in some other way that prevents this failsafe mechanism from working or has the part that's been implemented on the ESP to handle this not yet been ported to the Pi since it's still relatively new? The Pi Foundation typically invests a lot into good support [citation needed], so I'd lean more into it being a hardware limitation somehow. Anyone have any clues? Thanks.

[peterhinch]

The best way to develop on any platform is to create a module with your code which you can test at the REPL. When you've debugged it and want it to run on boot, write a main.py that looks like this:

import time
time.sleep(3)
import my_module

The brief delay enables you to get access by entering ctrl-c before your code starts. That way even if your code locks up in some way, you can easily get access after a reset or power cycle. This technique may be more necessary on bare metal ports like Pyboards and Picos - I've been doing it that way since before the ESP8266 was invented so I'm not in a position to compare.

I have used Picos and Pico W boards quite extensively and they are rock solid reliable.

[jimmo]

@MoffKalast there were a couple of commits that were merged after v1.19.1 was released that fixed issues that match what you're describing. In particular there was one where enabling the second core in particular caused problems for receiving Ctrl-C. Which firmware version are you using? (Would be interested to know if this still happens on the nightly builds)

Agree on the difficulty with getting out of this state. On the STM32 port we rely on most boards having a "user switch" that we use at boot to trigger safe mode or flash reset. See #8862 for a suggestion for the rp2 port.

[MoffKalast]

The brief delay enables you to get access by entering ctrl-c before your code starts.

Ah that's a neat trick that's good to keep in mind, though at times it just seems to crash the IDE backend instead. I guess it just needs to work once to recover though.

Which firmware version are you using? (Would be interested to know if this still happens on the nightly builds)

It has been a few months since I last checked what happens, and surely enough I can't get it to lock up on 20221118-unstable-v1.19.1-705. If the script crashes it just returns to REPL.

Well done guys, fantastic news 👍

I am seeing a lack of printouts when a script is ran automatically at boot vs. with import boot, which I assume is part of the solution. At least on the ESP I vaguely recall it being much harder to break execution with heavy printouts. It's not something one really needs when actually running it in a production setting I suppose though, so that's fine by me.

Edit: Ok actually when testing it with a raw serial link it seems to be running printouts fine, I probably just need to update the IDE side as well. 🤔

On the STM32 port we rely on most boards having a "user switch" that we use at boot to trigger safe mode or flash reset.

Well the Pico dev boards do have the bootsel button that switches to USB mode, not sure if that's possible to override? Ultimately though you might be trying to recover on a custom RP2040 board or with it packed inside a sealed case, so having a software break is definitely a better option.

[jimmo]

Well the Pico dev boards do have the bootsel button that switches to USB mode, not sure if that's possible to override?

It is possible to use bootsel as a regular button (with some tricks), but unfortunately turning it into a "do something different at boot" button is hard (because that's what it already does).

I am seeing a lack of printouts when a script is ran automatically at boot vs. with import boot,

General rule: unless there's a very specific reason you need to put something in boot.py (usually to do with configuring the board's startup procedure, in particular filesystems), don't put it in boot.py.

The exact behavior varies across ports, but for example on STM32, boot.py is responsible for configuring the USB mode, so the USB serial isn't available until after boot.py runs.

[jimmo]

It has been a few months since I last checked what happens, and surely enough I can't get it to lock up on 20221118-unstable-v1.19.1-705. If the script crashes it just returns to REPL.

Cool, I suspect what you were seeing was this:
#8869