RP2040 (Pico) suddenly unable to connect [USB issue]

General Discussion
1

I have an issue where RPi Pico which I’m using as a fan/adxl controller suddenly won’t connect when I restart the main RPi board.

Both Spider and Pico are connected to RPi 4B via USB, and they were happily working for half a year. Couple of weeks ago, I’ve run an update of everything (RPi system packages, Klipper, Mainsail, Moonraker, and the mcu code for both Spider and Pico). I’ve got no immediate issues after the update. I was able to start the print. However, halfway through the print, I’ve lost WiFi connection to the printer - however, it was still printing and eventually the (quite large) print finished successfully.

I have found out that what helps is to reconnect USB cable only after RPi is fully running.

I’m using the following boards in my setup:

  • Raspberry Pi 4B
  • FYSETC Spider v1.1
  • Raspberry Pico

What’s interesting is that this problem only manifests for Pico running Klipper. When I try to connect Pico without Klipper installed, I can restart the RPi and I still see the Pico connected.

I’ve done extensive debugging to find out what’s going on, but no luck so far. Let me walk you through it. First, the Pico with Klipper is not visible with lsusb after the restart. This is what dmesg contains:

[146678.328959] usb 1-1.1: USB disconnect, device number 14
[146678.643925] usb 1-1.1: new full-speed USB device number 15 using xhci_hcd
[146678.744199] usb 1-1.1: device descriptor read/64, error -32
[146678.964188] usb 1-1.1: device descriptor read/64, error -32
[146679.183932] usb 1-1.1: new full-speed USB device number 16 using xhci_hcd
[146679.284189] usb 1-1.1: device descriptor read/64, error -32
[146679.504179] usb 1-1.1: device descriptor read/64, error -32
[146679.624574] usb 1-1-port1: attempt power cycle
[146680.283924] usb 1-1.1: new full-speed USB device number 17 using xhci_hcd
[146680.284255] usb 1-1.1: Device not responding to setup address.
[146680.504158] usb 1-1.1: Device not responding to setup address.
[146680.723919] usb 1-1.1: device not accepting address 17, error -71
[146680.823926] usb 1-1.1: new full-speed USB device number 18 using xhci_hcd
[146680.824180] usb 1-1.1: Device not responding to setup address.
[146681.044208] usb 1-1.1: Device not responding to setup address.
[146681.263967] usb 1-1.1: device not accepting address 18, error -71
[146681.264563] usb 1-1-port1: unable to enumerate USB device

I did some googling, and the sugestion is that this issue is caused by inadequate power delivery or cable. Well, I have bought a pretty expensive and short cable with guaranteed 3A delivery, no luck.

So I have tried to buy an active USB hub to deliver more power (3A max) in case that the Pi wouldn’t be able to deliver it. Again, no luck - also I can’t imagine why the Pico would need anything even close to that power.

I was also curious if it helps when I power cycle the USB port using software. So I have installed uhubctl. This is how the usb hub looks like when everything is OK (see Port 1: 0103):

pi@fluiddpi:~ $ sudo uhubctl
Current status for hub 2 [1d6b:0003 Linux 5.10.103-v7l+ xhci-hcd xHCI Host Controller 0000:01:00.0, USB 3.00, 4 ports, ppps]
  Port 1: 02a0 power 5gbps Rx.Detect
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 02a0 power 5gbps Rx.Detect
  Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 1-1 [2109:3431 USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0103 power enable connect [1d50:614e Klipper rp2040 E6609CB2D3243128]
  Port 2: 0100 power
  Port 3: 0503 power highspeed enable connect [046d:0892 HD Pro Webcam C920 4E1C7DDF]
  Port 4: 0100 power
Current status for hub 1 [1d6b:0002 Linux 5.10.103-v7l+ xhci-hcd xHCI Host Controller 0000:01:00.0, USB 2.00, 1 ports, ppps]
  Port 1: 0503 power highspeed enable connect [2109:3431 USB2.0 Hub, USB 2.10, 4 ports, ppps]
11:37
Linux fluiddpi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux

I can turn it off:

Current status for hub 1-1 [2109:3431 USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0000 off

And back on:

Current status for hub 1-1 [2109:3431 USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0101 power connect []

Which is exactly the state in which the port is after restart as well.

I’ve tried rolling back Klipper to the point in time when I knew everything was working, no luck. Since there was no change to the hardware, I suspect that it must be collision between updated RPi firmware and Klipper (as firmware was one of the things that the system package updade performed). But it is just a guess.

Also - I have tried several Pico boards, some of them with nothing attached to them, just Klipper installed. Still the same problem. So this is definitely not an issue with that specific board.

Is there anything else I could try to find where the problem is?

2

It may be the rp2040-e5 errata. There was some discussion of this at rp2040: implement fix for RP2040-E5 errata by dalegaard · Pull Request #4748 · Klipper3d/klipper · GitHub . Note that this only impacts the initial OS detection of the pico - it should not impact anything after the OS detects the device.

-Kevin

3

Not sure if it’s the same issue being reported here, but I’ve had intermittent issues with the SKR Pico, as have several other people. I’ve experienced this issue regardless of connection type(serial and USB). Conversation on BTT GH here.

4

@jakep_82, I believe that we both face the same issue, and I also believe that it is related to the discussion that @koconnor linked. Now the question is what to do about it :slight_smile: .

What puzzles me that everything was working just fine until some point in February (roughly). And since I’ve tried to rollback Klipper with no effect, I suspect that something changed on the Raspberry Pi side.

@koconnor let me know if I can somehow help to debug this.

5

I have the same problem.
I designed three different kind of boards with rp2040, and they all have this problem. I also try the RPi Pico board，the problem also exists.The version of rp2040 is B2，rp2040-e5 errata was fixed in this version.

6

FYI, Klipper was extended to work around the “rp2040-e5 errata” a couple of months ago: Implement rp2040 workaround for USB errata "rp2040-e5" by KevinOConnor · Pull Request #5552 · Klipper3d/klipper · GitHub

I don’t have any further ideas of what would cause USB instability on the rp2040.

-Kevin

7

Unfortunately that didn’t help. I’ve tried to update the firmware in Pico many times since #5552, but I always need to unplug the pico after I reset RPi.

8

I have the same problem by using a original pico with the actual CanBoot or Klipper Firmware.
If there is no CanBoot or Klipper Firmware on it, the pico is recognized every time the RPI starts or reboots.

9

I’ve figured out this workaround and it work for me.

##Workaround to connect rp2040 on startup or reboot
sudo apt install uhubctl

sudo nano /etc/rc.local

place this before “exit 0”

uhubctl -l 1-1 -a 2
sleep 1 && uhubctl -l 1-1 -a 2

10

Somewhat old topic but I have the exact same problem with the RP2040 and no USB detected by the Raspberry Pi. The difference is that I use an SKR Pico as the control board and I am pretty stuck. I have looked around at the various suggestions and workarounds with no luck testing them all. The reset USB-hub doesn’t work since the SKR Pico get its power from external 24V and in turn power the Raspberry. If I fiddle around with stopping the Klipper service and press the reset switch a bunch of times I occasionally get the port detected and then everything is fine.
I run MCU version v0.11.0-124-gb2178f49 and the RP2040 is of the -B2 version. Raspberry Pi 3B with Mainsail OS.
I currently run this loop with the appropriate jumper wire installed and the Klippy service stopped:
port=/dev/serial/by-id/usb-Klipper_rp2040_45503571271173B8-if00

while ! [ -e “$port” ]
do
echo “SKR pico is not found”
raspi-gpio set 26 op
raspi-gpio set 26 dl
sleep 0.1
raspi-gpio set 26 dh
raspi-gpio set 26 ip
sleep 2
done
echo “SKR pico is found!”

But no device found after a long while. And I tried the serial port option as well.
Any ideas or suggestions would be greatly appreciated!

11

So I finally made it! Thought it would be helpful to someone else too.
I have a script looking for the RP2040 to show up after a reset-cycle:
cat << EOT > /usr/local/bin/restart-skr-pico.sh
#!/bin/bash
while ! lsusb | grep -i “rp2040”
do
raspi-gpio set 26 op
raspi-gpio set 26 dl
sleep 0.1
raspi-gpio set 26 dh
raspi-gpio set 26 ip
lsusb
sleep 3
done
echo “RP2040 is found!”
ls /dev/serial/by-id/*
EOT
chmod +x /usr/local/bin/restart-skr-pico.sh

And then execute it before the klipper service start:
sudo mkdir /etc/systemd/system/klipper.service.d
echo -e ‘[Service]\nExecStartPre=/usr/local/bin/restart-skr-pico.sh’ | sudo tee /etc/systemd/system/klipper.service.d/restart-rp2040.conf
sudo systemctl daemon-reload

I have re-used lots from

but added/changed some.

Have tried it a couple of times and it has to cycle typically three times before success.

12

FYI, Klipper was updated to handle USB bus resets on the rp2040 ( Handle USB resets on rp2040 by KevinOConnor · Pull Request #6182 · Klipper3d/klipper · GitHub ).

-Kevin

1 Like