Code running from flash that I can't stop

[kjm1102]

When I started with upython 5 years ago on pycom devices I could always kill a program with ctrlC in the repl and this worked if the program was running from flash or ram.

With rpi 2040s and the current crop of esp32s I'm finding it impossible to terminate code running from flash, which means having to reflash the chip with upython each time I want to upgrade a main.py in flash since previous posts on this problem don't offer much in the way of solutions other than a hardware fix (like adding a press button that the code checks to see if you want to terminate it).

Just wondering if anyone is familiar enough with the old pycom flavour of upython to explain why flash based code apparently listened on the USB & why this doesn't happen now days?

[steveh127]

Odd. I use both RP2040 and a variety of Esp32 chips both S3 and C3 with the latest builds and have no problem breaking into REPL with ctrlC. I'm using mpremote to communicate with the boards. My main.py is normally a simple import of the actual program.

If all else fails you can try using mpremote to overwrite the existing main.py even with the program running - works for me. Alternatively simply put a short delay at the top of main.py to give you time to break in.

[robert-hh]

@kjm1102 Unless the code disables breaking on ctrl-c or is running in a short viper type loop, interrupting by ctrl-c should work. At least as seen by the board. A IDE like Thonny may filter keyboard characters. Does this behaviour also apply if you use a simple terminal emulator like Putty or screen?

[peterhinch]

Normal Python code can be interrupted with ctrl-c. Exceptions are code that issues machine.deesleep() and code that runs loops in C or inline assembler - if these run for too long they can disrupt the USB interface. I'd investigate with a simple Python loop:

import time
while True:
   print("Hello")
   time.sleep(1)

If this can't be interrupted your IDE is swallowing the ctrl-c characters (as suggested above).

[scruss]

the RP2040 port can also disrupt the USB interface via time.sleep_us(). This is in the process of being fixed

[kjm1102]

Yeah the problem with the RP2040 is ghubcoder's upython (https://ghubcoder.github.io/posts/deep-sleeping-the-pico-micropython/) fork that does low power deepsleep via picosleep.seconds(). I thought it did bad things to the USB only after the first dormancy, but I was wrong.

[sophiedegran]

You can also make a try on launch your Project with an except KeyboardInterrupt, that work well for me..

[gitcnd]

Make yourself a boot.py which lets you prevent main.py from loading when necessary?

# This file is executed on every boot (including wake-boot from deepsleep)
import machine
# if booting is broken, pressing GPIO0 when the boot is stuck in the loop will avoid running whatever was broken...
if machine.Pin(0,machine.Pin.IN,machine.Pin.PULL_UP).value():
        exec(open("main.py").read())
else:
        print("GPIO0 Asserted: skipping boot")
#import webrepl
#webrepl.start()