I started to work on the rp2040 again. You can see my notes for the new setup here.
My problem is with the USB examples from pico_examples. None of the two usb programs is recognized by the OS. The response (dmesg) on Linux is:
[11044.261518] usb 1-3.3: new full-speed USB device number 40 using xhci_hcd
[11044.341540] usb 1-3.3: device descriptor read/64, error -32
[11044.529540] usb 1-3.3: device descriptor read/64, error -32
[11044.717575] usb 1-3.3: new full-speed USB device number 41 using xhci_hcd
[11044.797623] usb 1-3.3: device descriptor read/64, error -32
[11044.985569] usb 1-3.3: device descriptor read/64, error -32
[11045.093665] usb 1-3-port3: attempt power cycle
[11046.973633] usb 1-3.3: new full-speed USB device number 42 using xhci_hcd
[11046.973751] usb 1-3.3: Device not responding to setup address.
[11047.181789] usb 1-3.3: Device not responding to setup address.
[11047.389646] usb 1-3.3: device not accepting address 42, error -71
[11047.469673] usb 1-3.3: new full-speed USB device number 43 using xhci_hcd
[11047.469812] usb 1-3.3: Device not responding to setup address.
[11047.677812] usb 1-3.3: Device not responding to setup address.
[11047.885666] usb 1-3.3: device not accepting address 43, error -71
[11047.885729] usb 1-3-port3: unable to enumerate USB device
What is necessary to use the USB port of a rp2040?
Thanks, Jeremy, for your example project. I’m not sure if my problem is related to the Ada code.
First I tried with a RP2040 Zero. The flashed device was never recognized by Linux or Windows as a valid USB device, see yesterday’s post.
I then tried with a real Raspberry Pi Pico board. That is recognized as a serial input and a corresponding tty gets setup on Linux (/dev/ttyACM1). The new problem then, however, is that I cannot interact with the device. I tried several programs (minicom, cutecom, hterm) to no avail. The LED stays on, no matter how often I send a 0 or a t.
Only when I disconnect and reconnect my input seems to be transmitted and the response comes several times. Does the USB protocol require some kind of flush procedure? I had never seen that behaviour when working with other pseudo serial USB devices.
I use tio. I’m not sure what would cause the behavior you’re seeing. Maybe try reducing Max_Packet_Size to 1? That should force it not to buffer anything.
Do you have a lot of devices connected to the USB bus? Hardware errata RP2040-E5 says the chip has issues in this scenario. We did add the recommended workaround for this to rp2040_hal, but I was never able to reproduce the original issue on my system, so it’s possible we got the fix wrong.
Maybe try plugging it into a USB hub instead? If you’re already using a hub, try a different one?
RP2040-E15 says there are issues with a specific host controller chip (VL805). If your machine uses this, you might be able to update the firmware.
Likely irrelevant to this discussion, but in all variety of ARM boards I dealt with, from RPI to routers, none had USB 3.0 worked properly. E.g. in order to use an external USB drive I had to use either USB 2.0 port or else a USB 2.0 cable.
It works with tio on Linux and TeraTerm on Windows. It does not work with hterm, neither on Linux nor on Windows. I usually use the screen as a USB hub, but I have the same results if I plug it directly into one of the front or rear ports of the computer.
I don’t know how to determine the host controller chip. Linux boot up messages don’t tell me and I don’t want to open my computer.
That a device is not recognized by the OS is probably due to the cheap RP2040 clone from Aliexpress. These clones seem to be known for their bad quality.