Cannot init USB devices in boot.py
I tested this on a pico running MP 1.23 and the latest release of usb-device-cdc.
boot.py:
import usb.device
from usb.device.cdc import CDCInterface
IFACE_TWO = CDCInterface()
IFACE_TWO.init(timeout=0)
#usb.device.get().init(IFACE_TWO, builtin_driver=True)
main.py:
from time import sleep_ms
def main():
while True:
print(IFACE_TWO)
sleep_ms(1000)
if __name__ == "__main__": main()
Running this as-is, IFACE_TWO does show up in main.py, but uncommenting the init function causes the process to error out. This discord post suggests you can call usb.device.get.init() in boot.py, is this no longer true?
If boot.py doesn't exit then rp2 port will never initialise USB (soft-bricked)
Port, board and/or hardware
Raspberry Pico
MicroPython version
MicroPython v1.23.0 on 2024-06-02; Raspberry Pi Pico with RP2040
Reproduction
I took my program code and stripped it down to a working repro. There are more lines that could be deleted but help with visualization. The content is saved to boot.py. There is no other file saved on the microcontroller.
With any version prior 1.23 this will yield a serial device in device manager, whenever the device is connected to the computer. With version 1.23 it will not and can only recovered by flashing a firmware version prior 1.23:
import _thread
import asyncio # type: ignore
from time import sleep
import gc
import machine
synchronousLoopAlive: bool = True
anyLoopAlive: bool = True
led = machine.Pin(25, machine.Pin.OUT)
async def yieldingBackgroundTaskOne():
while anyLoopAlive:
print("One")
led.value(not led.value())
await asyncio.sleep_ms(1000)
def synchronousTask():
while synchronousLoopAlive:
sleep(2)
if __name__ == "__main__":
try:
sleep(3)
loop = asyncio.get_event_loop()
gc.collect()
programThread = _thread.start_new_thread(synchronousTask, ())
print("program thread started")
taskOne = loop.create_task(yieldingBackgroundTaskOne())
print("task One started")
loop.run_forever()
except KeyboardInterrupt:
synchronousLoopAlive = False
anyLoopAlive = False
loop.stop()
print("INTERRUPTED - STOPPING EVERYTHING")
except Exception as e:
print(f"error occurred: {e}")
Expected behaviour
Expected a serial device in device manager as in all versions prior 1.23.
Observed behaviour
No serial device in device manager with micropython 1.23, but with any version prior 1.23.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
Please give some more details about this means: what exactly do you do, and what error output do you see?
A soft reset (i.e. Ctrl-D in the REPL) will still disconnect the USB port each time, because the runtime USB interface objects have to all be freed and recreated.
A hard reset (i.e. plugging the rp2 in, or calling
machine.reset()) should come up immediately with the two CDC ports.The only difference between boot.py and main.py is that the first time the device boots from a hard reset, it runs boot.py before it initialises USB. If you put the code in main.py instead of boot.py then the rp2 would first try create a device using the default USB interface, then immediately switch to the custom USB interface. This can show up on the host as connect/disconnect/connect cycle, or as an error depending on the timing.
With the init line commented out in boot.py:
mpremote fs cp boot.py :mpremote run main.pyI see the print statements I expect:
With the init line uncommented in boot.py:
mpremote fs cp boot.py :mpremote run main.pyI do not see the print statements I expect:
I get dropped back to the terminal, and connecting with
mpremote a0yields no output. Attempting to replace boot.py even after unplugging/replugging the pico also yields the above OSError; I have to drop to a shell and useos.unlink().Ah snap,
mpremote rundoes a soft reset before it runs the provided file. Because boot.py has loaded the custom USB interface, it disconnects the USB port every time (then boot.py runs and adds it back, so you end up where you started.)If you copy both boot.py and main.py to the filesystem then main.py works and you can use
mpremote a0to view the output, but you still can't usempremote runany more.I think the fix for this will be the planned work to have mpremote detect when the USB port is in a disconnect/reconnect cycle, and recover from it instead of erroring out.
Is there a timeline for when the planned work might be finished?
Not at the moment, I'm afraid.
I assume this is impacting
mpremote connectas well (also including a soft reset)? Running similar as the OP above, I'm finding that I can connect directly to REPL by connecting to its COM port - but not usingmpremote connect.Not sure if anything has changed since the last update here - though revisiting this a year later, now on MicroPython v1.27 - everything seems to be working, and I'm not sure I can find a way to make it not?
I'm seeing success with both (separately) MicroPico 4.3.4 in VS Code, and mpremote 1.27.0.
Curious if anyone else here still watching can help test / validate? Thanks!
Though for reasons I don't yet fully understand, having
usb.device.get().init(...)included as part ofboot.pyinterferes with running "MicroPico: Run current file on Pico" (micropico.run) from MicroPico in VS Code.Disabling "Micropico: No Soft Reset On Run" (
micropico.noSoftResetOnRun) seems to then resolve this.Though then, and I suspect unrelated, I get into trouble if I try using Ctrl+C to quit a loop - same as reported in https://github.com/paulober/MicroPico/issues/294 - though pretty sure this is an issue with MicroPico and not micropython.