USB host (max3421) busy_lock not reset after failed bulk-in transfer

[smurferl]

Operating System

Others

Commit SHA

latest master

Board

Adafruit Feather nrf52832 + USB Host Featherwing (max3421)

Firmware

custom firmware based on based on examples/host/cdc_msc_hid (only enabled CDC), compiled with nrfsdk 2.9.2 based on Zephyr.

What happened ?

I'm working on a small device (USB Host) to connect my Rowing machine (CDC Device) to translate received data to be tracked by my sports watch.

What I've stumbled accross is, that after a couple of unplug/plug-in cycles, enumeration isn't performed anymore on plugging in the usb cable again.
After bit of investigation I found out that there seems to be a sort of a race condition, that there isn't (or too late) triggered an interrupt by the max3421 after starting the last bulk-in transfer before hardware disconnect. This leads to not resetting the "_hcd_data.busy_lock" and therefore no enumeration takes place after connecting the (any) device again. In case the interrupt is correctly triggerd, the hrslt register contains an error due to the disconnect (0x0D hrJERR J-state instead of response), which causes the busy_lock flag to reset correctly.

If disabling CDC, so only regular enumeration takes place (without the bulk-in transfers on every USB frame), there is no issue as no running transmissions are intercepted by unplugging the USB cable.

For my purpose and as a workaround, I'm now resetting the flag to false, when receiving the connection interrupt and detecting a disconnect in handle_connect_irq (hcd_max3421.c). For sure not the most elegant way of doing it and it might not be working correctly for any usecase, but it at least makes things passing for my project.

Just wanted to raise that issue for two reasons:

1. point out a possible rootcause for similar issues, others might have
2. maybe someone as a good idea how to resolve that issue in a better way, so it could also be added to the tinyusb codebase

How to reproduce ?

1. Run CDC Host example in a setup that uses max3421 as host IC
2. plug in a CDC device
3. wait for enumeration to be finished and plug out the device again
4. rinse and repeat point 2/3 until enumeration stops at sending the initial setup request "Get Descriptor: 80 06 00 01 00 00 08 00"
5. firmware will not recover unless a device reset is performed

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

No meaningful log available, as it simply stops at sending the initial setup packet, since the busy_lock flag is still indicating the max3421 to be busy.

Screenshots

No response

I have checked existing issues, discussion and documentation

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

[smurferl]

added logfile that shows the full connection process, incl. the partially happening 0D error on disconnect (which does prevent hanging on connecting the device again, since the busy_lock is reset)

hrsl_0x0D.txt

[hathach]

thanks for the issue, I will check this out the next time I work with max3421e port (currently busy with other things)>