usbh: 10 ms reset recovery + hcd fail-fast + no enumeration retry leaves devices behind a hub permanently absent #3876

Activity

1. hathach commented on Oct 5, 2026

   

   hathach

   on Oct 5, 2026

   Owner

   More actions

   #3862 (430fcd2) adds the missing enumeration retry: a device that fails an enumeration control transfer is torn down and re-enumerated from address 0 after a fresh port reset (CFG_TUH_ENUM_ATTEMPT_MAX, default 2), and a control transfer that never completes now times out after CFG_TUH_CONTROL_TIMEOUT_MS (5 s). The 10 ms reset recovery delay is unchanged.

   Could you test current master on your RP2350 + hub setup and report whether all devices mount?
2. UKTailwind commented on Oct 7, 2026

   

   UKTailwind

   on Oct 7, 2026

   Author

   More actions

   Thanks. Tested master at e42fa93 (which includes #3862) on the same board: a Pico Computer 3 (RP2350B, native controller in host mode) with a keyboard, mouse, gamepad and USB flash drive behind its on-board hub, built into our PicoMite (MMBasic) firmware rather than MicroPython.

   The retry replaces all of our usbh.c workarounds, but on its own it is not enough: we still need a bounded RX-timeout hold-off in hcd_rp2040.c.

   Build	Result
   master + our other RP2 driver fixes (including #3874 and #3875), stock usbh.c, no hold-off	the gamepad and flash drive mounted; the keyboard and mouse did not, although the hub had powered all four ports
   the same + the hold-off below	all four mounted every time: 5 software restarts, 4 reset-button resets, 4 power-ons and hot-plugging on one firmware variant, and 4 of each reset type on three more variants

   With the hold-off and master's retry, the three usbh.c changes we carried on 0.21 are no longer needed, and we have dropped them: the 100 ms reset recovery, disabling the hub port of an abandoned enumeration, and holding application control transfers back while a device enumerates.

   The hold-off restores 0.20's behaviour for endpoint 0 only, for a bounded time. For 1 s from the first EP0 RX_TIMEOUT, the timeout is cleared and the transfer is left armed, so the SIE keeps retrying. After that, the existing STOP_TRANS + XFER_RESULT_FAILED path runs as before; it has to stay as the backstop (see the caution in the original report). Only an endpoint-0 completion closes the window: closing it on any completion let hub status and HID traffic re-arm it for ever. Bulk and interrupt endpoints keep failing fast, since a slow device NAKs there rather than timing out.

   #define CTRL_RX_TIMEOUT_GRACE_US (1000u * 1000u)
   static bool     ctrl_rx_timeout_timing = false;
   static uint32_t ctrl_rx_timeout_start_us;
   
   // xfer_complete_isr(): an endpoint-0 completion closes the window
   if (tu_edpt_number(ep->ep_addr) == 0) ctrl_rx_timeout_timing = false;
   
   // hcd_rp2040_irq()
   if (status & USB_INTS_ERROR_RX_TIMEOUT_BITS) {
     usb_hw_clear->sie_status = USB_SIE_STATUS_RX_TIMEOUT_BITS;
   
     // within the window, leave the transfer armed and let the SIE retry (0.20 behaviour);
     // no STOP_TRANS, which would cancel the retry
     bool in_grace = false;
     if (epx->state == EPSTATE_ACTIVE && tu_edpt_number(epx->ep_addr) == 0) {
       const uint32_t now = time_us_32();
       if (!ctrl_rx_timeout_timing) {
         ctrl_rx_timeout_timing   = true;
         ctrl_rx_timeout_start_us = now;
       }
       in_grace = (uint32_t)(now - ctrl_rx_timeout_start_us) < CTRL_RX_TIMEOUT_GRACE_US;
     }
   
     if (!in_grace) {
       // existing STOP_TRANS + XFER_RESULT_FAILED path, unchanged
       // (with usbh_dpram->epx_buf_ctrl = 0 before failing, #3874)
     }
   }

   We haven't instrumented master to see why the retry alone misses the keyboard and mouse. A likely reason is that the retry's fresh port reset is followed by the same 10 ms recovery, so a device that is slow after a reset is just as mute on the second attempt. A longer recovery delay on the retry might do the same job as the hold-off; we haven't tried that.

   #3874 and #3875 are still needed on master; we carry fixes for both.
3. UKTailwind commented on Oct 8, 2026

   

   UKTailwind

   on Oct 8, 2026

   Author

   More actions

   A follow-up to the hold-off above, now that #4166 (e204823) implements hcd_edpt_abort_xfer() and retires EPX in hcd_device_close(). Those end a control transfer without going through xfer_complete_isr(), so the window has to close there too. Otherwise a window opened by the aborted transfer stays open with its old start time, and the next endpoint-0 transfer, usually the enumeration retry after the teardown, finds it already expired and fails on its first timeout. In epx_retire(), inside the ep == epx && ep->state == EPSTATE_ACTIVE branch:

   if (tu_edpt_number(ep->ep_addr) == 0) ctrl_rx_timeout_timing = false; // an aborted/closed control transfer ends the window

   We have this on e204823 with the rest of our RP2 fixes rebased onto it. On the same Pico Computer 3 (four devices behind the hub) all four enumerate on every one of 5 CPU restarts, 4 reset-button resets and 4 power-ons, and flash-drive hot-plug is clean 5/5. We have not seen the abort path fire in those tests; the change follows from the code.
4. HiFiPhile

   added a commit that references this issue on Nov 12, 2026

   usbh: resend a failed enumeration request before resetting the port

   ...

   a3501df
5. HiFiPhile commented on Nov 12, 2026

   

   HiFiPhile

   on Nov 12, 2026

   Collaborator

   More actions

   @UKTailwind could you try #4484 ?