Unlug on CH334 Hub on RP2040 using PIO-USB fails with a broken unplug event

[harbaum]

Operating System

Linux

Commit SHA

8f2e3ed, current master

Board

Pi Pico 1 / RP2040

Firmware

Custom firmware for FPGA Companion https://github.com/MiSTle-Dev/FPGA-Companion

Running inside FreeRTOS, using PIO-PICO-USB, also latest master

This is actually extensively used for the MiSTle retro gaming project, where TinyUSB is used on a rp2040 to control keyboard, mouse and joysticks in a FPGA retro gaming setup.

What happened ?

Sometimes (with debugging enabled) or very often (without debugging), unplug events on a CH334 hub are missed and the stack goes nuts as it still tries to communicate with the now missing devices.

How to reproduce ?

Use the FPGA Companion on a MiSTle setup and unplug a device.

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

The HUB xfer callback for the unplug event fails:

[2] Claimed EP 0x81
  Queue EP 81 with 64 bytes ... 
OK
[:5] on EP 81 with 0 bytes: FAILED
  HUB xfer callback
[5] Claimed EP 0x81
  Queue EP 81 with 1 bytes ... 
OK

Afterward, the stack goes nuts as it didn't get the unplug event and still tries to communicate with the now missing devices.

If I ignore the test for a good result in

tinyusb/src/host/hub.c

Line 364 in 8f2e3ed

if (result == XFER_RESULT_SUCCESS) {

like so

  /*  if (result == XFER_RESULT_SUCCESS) */ {

Then, the broken message still contains enough information to actually handle the unplug event correctly. The status change byte is especially correct:

[:5] on EP 81 with 0 bytes: FAILED
  HUB xfer callback
  Processing failed hub cb, anyways
  Hub Status Change = 0x08
HUB Get Port Status: addr = 5 port = 3
[1:5] Class Request: A3 00 00 00 03 00 04 00 
[:5] on EP 00 with 8 bytes: OK
[:5] on EP 80 with 4 bytes: OK
[1:5] Control data:
  0000:  00 01 01 00                                      |....|
[:5] on EP 00 with 0 bytes: OK

Everything works fine, now. This is ok for now, but this doesn't sound like a good solution.

How would I debug this further? The hub is soldered on-board, so I cannot simply test a different one.

I'll try to set up a bare-bones system with a different hub. I'll also try to set up a variant that uses the RP2040's native USB vs. the PIO-USB we are currently using (and which we'd like to continue using, as PIO can be used through the pin headers).

Screenshots

No response

I have checked existing issues, discussion and documentation

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

[hathach]

there is no way for me to reproduce this. Did the issue occur with standard PICO + ch334 hub breakout https://www.adafruit.com/product/5997?srsltid=AfmBOorxxg4urH2TaKiIJxCo9qGPV8zi_PXtvnmkGWHy3I9VnrJ7Jd9f

[harbaum]

I am aware that it's not easy to reproduce. I am not expecting you to debug this. But you may have some ideas and hints.

I'll try to reproduce this with a minimal setup and also see if different hubs or the rp2040's native port make a difference.

I'll report here about my findings.

[hathach]

please also try to reproduce it with standard pico + ch334 hub to rule out if it is hardware related issue as well.

[harbaum]

Some more results:

• the same happens in a minimal software setup, basically only running tinyusb on freertos
• the same happens with an off-the-shelf Pi-Pico with an off-the-shelf CH334 hub
• the same happens with a different hub

The same does not happen if I use the rp2040's native USB. So this may actually be a problem with pio-usb rather than the tinyusb stack itself.

Interestingly, some devices also don't enumerate anymore since I updated from the current pico-sdk to the latest tinyusb and pio-usb.

I'll do some more research.

[harbaum]

Interestingly, the enumeration issues that have come with the latest tinyusb/pio-usb only happens with a CPU clock < 156Mhz. At higher CPU speeds, these are gone. However, the hub/unplug issues seem to be unaffected by this.

[harbaum]

This may be related/the same issue:

sekigon-gonnoc/Pico-PIO-USB#149

[hathach]

This is pio timing/race condition. I fixed/improved a similar issue here sekigon-gonnoc/Pico-PIO-USB#186 . Basically CPU does not reponse fast enough within USB timing specs and peer consider it as a timeout. Pleasethe stock example host/device_info on bare metal instead of freertos. I have never tried rp2040 with freertos, last time I tried, and make an PR to pico-sdk but it got zero feedback.

[harbaum]

I haven't tested without freertos. But with my minimal test setup it shouldn't be too complex to do.

Unfortunately that won't be a solution for my application. But I'll give it a try, anyways.