Giters

Allen-Synthesis / EuroPi

EuroPi: A reprogrammable Eurorack module based on the Raspberry Pi Pico

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug Report] Pico does not connect to Thonny under normal conditions

roryjamesallen opened this issue · comments

commented

Bug Report

When connecting a EuroPi running at least the newest version of MicroPython, Thonny fails to connect to the Pico, either giving a 'Device is busy or does not respond' error (or similar) or failing to show up in Thonny at all.

Windows often gives a 'USB device not recognised' message.

To Reproduce
Steps to reproduce the behavior:

  1. Do not have rack power turned on
  2. Have the Pico installed in the module
  3. Plug the module (Pico) into a computer via USB
  4. Open Thonny and press stop to attempt to make a connection
  5. The device does not show up

Expected behavior
The module should connect in this order of events, and in the past it did

Images
No Pico shown despite USB connection:
image

Windows USB message:
image

Additional context
This order of events has worked fine for programming in the past, so something in either the firmware, MicroPython version, or OS update has changed.
You can still program the module by either

  1. Plugging the Pico in via USB and making the connection before plugging the Pico into the module itself
    or
  2. Plugging the module into power (with the Pico installed) and waiting for it to boot fully, and then connecting it to a computer via USB
commented

Important discovery

Adding a sleep(1) to the start of main.py (menu.py), prevents this issue from occurring, at least on my machine.
I can remove the sleep(1) and the issue will re-arise immediately and consistently, and add it back in and it will vanish.

Based on this, I think that some kind of interference between Thonny/MicroPython/EuroPi firmware is occurring, specifically that the running of main.py automatically and immediately upon power-on prevents a reliable USB connection from being established.

The fact that adding this delay fixes the issue also lines up with the fact that booting the module via rack power is also a workaround, as it means the USB connection and main.py booting happen at different times, so main.py cannot interfere and block the USB connection.

commented

Not yet tested but polling GPIO24 would allow a different operation if connected via USB.
If USB is connected, GPIO24 will be high, so a single if statement would be sufficient to for example add the delay as above only if connected to USB, and not have to delay scripts that are running solely on rack power (where this issue does not need to be accounted for)

commented

This issue is currently solved by a workaround, the removal of which is documented in #184