panic on hid device enumeration with a particular hub

[learmj]

Operating System

Others

Board

Raspberry Pi Pico

Firmware

examples/host/msc_file_explorer

What happened ?

A customer sent us a product they designed based on our RP2040. They also supplied a usb hub which they reported caused problems with hid device enumeration when the hub was connected to their product. Debugging the problem on one of our Pico boards with our SDK, I can see that the tip of tinyUSB today exhibits the problem which is that there is a panic in tinyUSB when a hid device (a USB keyboard in this case) is plugged into the hub. Using the same hub and hid device with other embedded products (eg Raspberry Pi 5) or a linux laptop exhibits no such problem. At the moment, it's unclear why it occurs with the Pico.

The tinyUSB I'm using to test is currently at commit:

1577572 - (HEAD -> master, origin/master, origin/HEAD) Merge pull request #2492 from tlyu/fix-rp2040-ctrl-xfer (2024-03-13 12:02:08 +0700)

The difference between the working and not working scenarios appears to relate to retrieval of the configuration descriptor at a point in the enumeration sequence. I'm guessing there is a stall and the transaction does not complete for some reason.

Good:

Get Configuration[0] Descriptor (9 bytes)
[0:1] Get Descriptor: 80 06 00 02 00 00 09 00
Transfer complete
on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
on EP 80 with 9 bytes: OK
[0:1] Control data:
0000: 09 02 3B 00 02 01 00 A0 32 |..;.....2|
Buffer complete
Transfer complete
on EP 00 with 0 bytes: OK

Bad:

Get Configuration[0] Descriptor (9 bytes)
[0:1] Get Descriptor: 80 06 00 02 00 00 09 00
Transfer complete
on EP 00 with 8 bytes: OK
*** PANIC ***

The hub has no discernible markings. I'm tempted to open it to try and find out more about it.

I've attached two log files. One shows the problem (captured with the problematic hub) and the other shows a successful attachment of the hid device (captured with a different hub).

I don't know what is causing tinyUSB to panic except that there is a data sequence error (presumably a catch all for a problem during the transaction processing).

It'd be great if someone could review the attached logs and possibly point me in the direction of other avenues to investigate further.

Many thanks.

How to reproduce ?

Pico powered by VBUS at 5V and operating as a USB Host

1. Load / flash the msc_file_explorer app into the Pico (I'm using openocd to load and execute the ELF)
2. With the hub connected to the Pico via an OTG cable before or after the app starts (it does not matter), connect the hid device into one of the ports on the hub
3. Plugging in another device (eg mass storage) into the hub results in no activity. All USB device use from this point is broken.

What actually happens is that at step 2, there is a panic and the following is observed on the serial console:

*** PANIC ***

Data Seq Error

Interestingly, if the hid device is not connected in step 2, the mass storage device can happily be plugged and unplugged from the hub and everything functions as expected.

The problem seems squarely related to the interaction between tinyUSB and plugging a hid device into this particular hub. The problem is not limited to a particular hid device either. I've tried a few different keyboards and mice and all behave the same way.

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

hub-ok.log
hub-panic.log

Screenshots

No response

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[RalphCorderoy]

A little bit of background. The problem came to my notice in Olimex's reason for creating a USB hub board where they gave some detail, including:

Unfortunately, in most cases, these cheap USB hubs, like the one we have on the web and many others, simply refuse to work. Out of the 10 USB hubs I bought to test, only 2 were functional.

[P33M]

With the hub plugged into a Pi, please post the output of sudo lsusb -v. Also busting it open and getting the controller IC part number would be useful.

[learmj]

Here's a log after connecting the hub.
Bus 001 Device 002: ID 214b:7250
after-hub-plug.log

[P33M]

It appears the hub is very flaky when talking to low-speed devices if operating in full-speed mode. I attach a Teledyne Lecroy analyser trace showing multiple errors - it appears the host hardware eventually gets upset. My suggestion would be to ensure consistency of the expected packet data toggle in the case of smashed ACKs.
pico host usb hid probe.zip

[RalphCorderoy]

Thanks @P33M, so the Pico host eventually gets upset. Did you try traces with other hosts, as Matthew tried a Pi5 and Linux laptop, and they also suffered the hub's flakiness but coped better?

[P33M]

Every single other host will use the hub in high-speed mode, which fundamentally changes the signalling involved - communication with the low-speed device is handed off to the hub's transaction translator. See the USB 2.0 spec section 11.14.1.1.