tinyusb icon indicating copy to clipboard operation
tinyusb copied to clipboard

MAX3421 as host: lost EP Rx transfer, race condition

Open IngHK opened this issue 1 year ago • 7 comments

Board

NUCLEO-WL55JC1 (STM32WL55 with LoRaWAN, but no internal USB controller), external MAX3421 as host

Firmware

own firmware running on STM32 based on STM32CubeWL Firmware Package v1.3.0

What happened ?

I've maybe found a bug, but I'm not sure... My application: STM32 with MAX3421 and TinyUSB host communicating with attached CDC device (RS232) The issue: CDC Tx bulk transfers are lost depending on timing relationship of Rx/Tx bulk tranfers

I analysed the USB endpoint traffic with USB sniffer hardware (https://www.bugblat.com/products/minisniff/), inserted between MAX3421 and CDC device, and I see the the Rx EP transfers, but tuh_cdc_rx_cb is not everytime called. It seems the failure appearance depending on the Rx/Tx timing relationship.

Is there still development in progress regarding MAX3421? What can I test or what do I have to care or check about my setup STM32WL and MAX3421?

How to reproduce ?

My current HW/SW setup is quite special... I'll try to create an easy reproducible constellation without special hardware in the next days. You can request any measurements you want to have from me. I've logic analyzer, oscilloscope and USB sniffer hardware in my lab.

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

There are no debug outputs, because the Rx EP transfer are lost as never happened.

Screenshots

No response

I have checked existing issues, dicussion and documentation

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

IngHK avatar Jan 06 '24 15:01 IngHK

Hi @IngHK, did you manage to solve the issue you had? I'm very curious because this is something that potentially might tell me whether is it relatively safe to use RX callbacks or should I rather use polling on RX.

kowalewskijan avatar Nov 05 '24 14:11 kowalewskijan

This should be fixed in the latest, please pull and try again

hathach avatar Nov 05 '24 15:11 hathach

I'm using v0.17.0 so I guess it should be fine? I suppose the issue can be closed to avoid confusion.

Thanks!

kowalewskijan avatar Nov 05 '24 16:11 kowalewskijan

should be fixed by https://github.com/hathach/tinyusb/pull/2731, but let wait for OP to confirm.

hathach avatar Nov 06 '24 03:11 hathach

It looks like the issue is still there in v0.17.0. When using tinyUSB in host mode with max3421 I observe that rx callback is lost after few (random number I think) consecutive operations over host cdc. When I add additional delay between operations it works normally.

Szewcson avatar Nov 20 '24 12:11 Szewcson

Hi! I am using v0.19 with an esp32 + max3421 and same happens to me (sometimes not rx cb and sometimes only one). But I guess it is because the HOST stops polling for some reason. I will upload the USB captured data. The window between the end of the enumeration and all the SOF timaouts at the end, I managed to receive one small thing. However, the IN transaction no longer occurs, and that is why the RX callback is not being called. Maybe I am dumb enough not to ralize the error.

scan_tu_timing_out_not_read4.csv

fbucafusco avatar Oct 24 '25 13:10 fbucafusco

BTW, debugging and trying to solve the issue, I have added a TU_LOG in uint32_t tu_edpt_stream_read_xfer(uint8_t hwid, tu_edpt_stream_t* s) just before the if (available >= mps) statement And, all the the RX callbacks are called properly and the host keeps polling the device. The log's text is edpt_stream_read_xfer available=512>=64? just so u know the length.

UPDATE: but, long term, fails anyway and the hub does not poll anymore

fbucafusco avatar Oct 24 '25 13:10 fbucafusco