USBD MSC re-plug required (with Windows Host)

[bencowperthwaite]

Hello,

I have a dual-lun MSC set up on an STM32U595 (Synopsis DWC2).
I'm using TinyUSB v0.16.0.
I'm using FreeRTOS, but I have a custom wrapper around the kernel, so I'm using OPT_OS_CUSTOM.

I have a strange issue, but I don't know whether the root cause is;

1. a TinyUSB bug
2. My TinyUSB config
3. A Windows "quirk"

The Symptoms

In general the set up works well; I can mount and access two storage devices in a host OS (Windows or Linux) and reliably read and write to them via TinyUSB. Performance is good (~8MB/s) and CPU overhead on the STM32U5 is low (Side note; thank you for your efforts with this project).

The only issue is this only works following a re-insertion of the USB cable!
It only applies to Windows hosts (tried on a couple of Windows 10 laptops), Linux hosts mount the storage devices first time (both embedded Linux systems and desktop Linux).
It doesn't matter whether I power on my STM32U5 with or without the cable already plugged in; if it is not plugged in, the first insertion will fail.

I can see interrupts being received by TinyUSB and the corresponding Events being handled bytud_task_ext() ; before first plug (controller reset), at first plug and then subsequent plugs. They look normal to me.

It could be a red herring, but what appears to happen is Windows "gives up" after sending short number (7) of Setup Events, before the transfer complete callback (complete_cb) is set by invoke_class_control().

Following a re-plug, there is an similar pattern of Setup and Xfer Complete Events, but they don't stop and after 16 Setup Events the complete_cb is set and normal behaviour resumes.

I could be way off the scent, but just in case it's useful, the Events handled by tud_task_ext() have the following patterns.
Where;

• Rst = Reset Event
• Stp = Setup Event
• Xfr = Xfer Complete Event
• Sus = Suspend Event
• xfer_cb! = complete_cb set to a non-null function pointer

Start of day (nothing plugged in)
Rst.

First Plug
Rst.Stp.Xfr.Xfr.Stp.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr. [large pause] Sus. [the trailing Suspend is not always present]

Second Plug
Sus.Rst.Stp.Xfr.Xfr.Stp.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Xfr.Stp.Xfr.Stp.xfer_cb!Xfr.Xfr.Xfr.Xfr.Xfr.Xfr.Xfr.Xfr.Xfr.Stp.xfer_cb!Xfr.Xfr.Xfr.Xfr.Xfr.Xfr... [success]
(if that makes any sense at all?)

Any help/suggestions would be welcomed.

[HiFiPhile]

I didn't met any issue with NUCLEO-U5A5ZJ-Q, please test with stock examples.

Also you can set CFG_TUSB_DEBUG to 2.

[bencowperthwaite]

In the end it was my implementation of tud_descriptor_string_cb(), specifically the STRID_SERIAL case: I was carelessly setting _desc_str[0] to the start of my UID, when it should start from _desc_str[1].
Why this resulted in the behaviour I observed in Windows is beyond my comprehension, but the lesson here for anyone with similar symptoms is to double check your usb_descriptors.c