USB problem on RPi pico
I have an issue with rshell that seems to be caused by the USB comms.
If I issue the command cp ports/rp2/examples/* /pyboard then rshell will hang, typically on the first file.
If I add some statements in the recv_file_from_host function in rshell (this is the part that runs on the pico) that opens a UART and logs some additional information to the UART, then the copies all succeed.
I tried adding 20 msec delays each place that there was log statement, but that doesn't seem to make things work either.
Sorry I don't have a simpler test case, but I figured I'd log the issue and see if I can create a simple program which reproduces the hang/crash.
Sometimes, things hang, and sometimes the serial port is forcibly closed (I suspect that this might be a crash on the pico side).
rp2: Recovering from EMI
I have several picos connected by 10 foot USB cables, plugged into a powered USB hub, which is then connected to a central host. The host will use USB/Serial to issue commands through RAW REPL shell. Each pico just has some initial setup code and a set of methods to interact with sensors, there is no looping code so they sit idle until a command is recieved.
One of the picos connects to a set of relays to control 110v power outlets. When a noisy device is turned on/off it will induce EMI in the USB cable and cause the host to timeout on serial commands. This can happen to any of the picos, but i can regularly reproduce it on the pico that controls the 110v.
In an attempt to narrow in on the problem, I can reproduce this on Windows 10, Ubuntu (18-22), and a raspberry pi 4 and I have tried 3 different USB hubs from 2 brands (They are all USB 3.0, i have tried with 3.0 cables and 2.0 cables to conenct with the host).
I have modified ports/rp2/mphalport.c and added logic in mp_hal_stdin_rx_chr to initialize the on-board LED upon entering and then either driving it high or low depending on the value of tud_cdc_connected()
In a test state, the LED turns on when a serial connection is open, and turns off when the serial connection closes. When the host is running, it makes 1 initial serial connection and keeps it open until the host is shutdown. Under the EMI condition, the LED stays on from the initial connection but serial writes timeout on the host.
I put in a hacky watchdog in this method so after a while, when nothing is recieved from stdin, it will call:
tud_disconnect();
sleep_ms(1000);
tud_connect();
And this will get the pico back in communication with the host and all is fine until i fire off another EMI event.
Now, I know any sane person would probably eliminate the source of the EMI, but now I have taken this as a challenge to try and figure out what state the pico is in, why it still thinks the serial connection is active, and possibly find a better way of detecting/recovering from this type of scenario.
I haven't narrowed in on the Pico as the actual problem. Sometimes i get messages in the host OS where it can see the hub reset the device and re-enables it, sometimes the host OS doesn't see any event, or sometimes i get 'can't read device descriptors' errors and the pico dissappears from the host.
When the host still sees the device as attached, a read always timesout, I can perform write operations until what i assume is a buffer filling and further writes will then time out.
I was hoping that someone might have suggestions on further debugging, has encountered something similar, or can provide any general guidance. I'd like a better approach to recovering from this rather than resorting to my hacky watchdog.
Thanks!