The MSC is no longer functioning properly

[traxanos]

I just noticed that my USB mass storage implementation is no longer functioning.

I have already determined that I now need to work with the new USB class.

I have done so, and my USB drive is now displayed correctly again, and I am able to write to the drive.

The issue arises when I attempt to eject the drive. In this case, an attempt is made to eject the serial rather than the USB drive. So I don't get a callback via tud_msc_start_stop_cb either. (Verified with a debug output via Segger RTT)
As a result, my data will no longer copied to the internal LittleFS.

If I am connected to the (USB) console at the same time, I also get an error from Windows saying that the serial port is still in use. But this used to work fine.

[earlephilhower]

Please provide a small MCVE that shows this. The SingleFileDrive example here were tested and working as part of the big USB upgrade.

There was a HID issue in #3208 but that was only on the HID report IDs, not the USB descriptors that are used to make MDS/Serial/MIDI work.

Also, if you were hard coding certain descriptor/report IDs they may no longer be valid. The programmable USB infrastructure could be assigning things differently than the older hardcoded multi-level if statement used to.

[traxanos]

I checked mine based on FatFSUSB and SingleFileDrive, and it does exactly the same thing.
The difference is that SingleFileDrive only provides data and FatFSUSB does not rely on eject, as no copying takes place after eject.
And no, I have not made any adjustments with USB.setVIDPID().

[earlephilhower]

Sorry, I don't understand what you mean. If I am parsing it correctly, you're saying the libraries here work but your app doesn't? Please provide a small MCVE that can show the issue so we can look at it and reproduce a failure.

[traxanos]

I was able to reproduce this with your samples a few times. The problem is that it doesn't always occur.

you can reproduce it with https://github.com/earlephilhower/arduino-pico/blob/master/libraries/SingleFileDrive/examples/DataLoggerUSB/DataLoggerUSB.ino

It looks like Windows always unmounts the file system when ejecting the volume. But sometimes it detach the storage device and sometimes it detach the COM port.

When Windows tries to detach the COM port, I can remount the volume via disk management console.

In this case, I also didn't get a callback for tud_msc_start_stop_cb.

If it correctly detach the storage device, a mount via disk managment console is logically no longer possible and I get the callback for tud_msc_start_stop_cb.

[earlephilhower]

I'm pretty sure that's just the way Windows is, either driver related or just general USB flakiness. Compound devices always are problematic (hence the hack of changing VID/PID when different peripherals are used in a sketch). Especially since you're saying it's random. FWIW under Linux I've never seen that...I don't think it's even possible to "eject" a /dev/ttyACM.

Initiating callbacks is 100% handled in low-level TinyUSB. It either gets a special packet or not and calls your CB as appropriate. If the USB host is messed up, there's no much TinyUSB can do.

This is where the new USB stack can help you. It's possible to disconnect the USB, change the VID/PID, remove the serial port and add a MSD device, reconnect the USB. Viola, a plain Jane USB stick as far as Windows knows. When the MSC gets an eject (it's the only thing active then!) you can disconnect the USB port, remove the msd, add the serial, change VID/PID, and restart USB. Voila, a plain Jane CDC serial port.

[earlephilhower]

Checking the git log in the SingleFileDrive shows almost 0 changes since it was merged in 2022, with the latest one only adjusting to call the appropriate USB.xxx methods instead of using the old weak symbol. No logic changes beyond the initialization bits.

I checked the generated device descriptors and they're basically identical with the following changes:

• The strings are different order, but that's completely immaterial
• Newer one used 0xef,0x02,0x01 for the device class (IAD) vs the 0/0/0
• The 4.7.1 version used fixed endpoints and left a gap when not used w/a HID device. That was legal but suboptimal. New one uses consecutive EPs

4.7.1 DataLogger.cpp via https://eleccelerator.com/usbdescreqparser/

0x12,        // bLength
0x01,        // bDescriptorType (Device)
0x00, 0x02,  // bcdUSB 2.00
0x00,        // bDeviceClass (Use class information in the Interface Descriptors)
0x00,        // bDeviceSubClass
0x00,        // bDeviceProtocol
0x40,        // bMaxPacketSize0 64
0x8A, 0x2E,  // idVendor 0x2E8A
0x0A, 0x00,  // idProduct 0x0A
0x00, 0x01,  // bcdDevice 2.00
0x01,        // iManufacturer (String Index)
0x02,        // iProduct (String Index)
0x03,        // iSerialNumber (String Index)
0x01,        // bNumConfigurations 1

0x09,        // bLength
0x02,        // bDescriptorType (Configuration)
0x62, 0x00,  // wTotalLength 98
0x03,        // bNumInterfaces 3
0x01,        // bConfigurationValue
0x00,        // iConfiguration (String Index)
0xA0,        // bmAttributes Remote Wakeup
0x7D,        // bMaxPower 250mA

0x08,        // bLength
0x0B,        // bDescriptorType (Unknown)
0x00, 0x02, 0x02, 0x02, 0x00, 0x00,
0x09,        // bLength
0x04,        // bDescriptorType (Interface)
0x00,        // bInterfaceNumber 0
0x00,        // bAlternateSetting
0x01,        // bNumEndpoints 1
0x02,        // bInterfaceClass
0x02,        // bInterfaceSubClass
0x00,        // bInterfaceProtocol
0x04,        // iInterface (String Index)

0x05,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x00, 0x20, 0x01,
0x05,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x01, 0x00, 0x01,
0x04,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x02, 0x06,
0x05,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x06, 0x00, 0x01,
0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x81,        // bEndpointAddress (IN/D2H)
0x03,        // bmAttributes (Interrupt)
0x08, 0x00,  // wMaxPacketSize 8
0x10,        // bInterval 16 (unit depends on device speed)

0x09,        // bLength
0x04,        // bDescriptorType (Interface)
0x01,        // bInterfaceNumber 1
0x00,        // bAlternateSetting
0x02,        // bNumEndpoints 2
0x0A,        // bInterfaceClass
0x00,        // bInterfaceSubClass
0x00,        // bInterfaceProtocol
0x00,        // iInterface (String Index)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x02,        // bEndpointAddress (OUT/H2D)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x82,        // bEndpointAddress (IN/D2H)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

0x09,        // bLength
0x04,        // bDescriptorType (Interface)
0x02,        // bInterfaceNumber 2
0x00,        // bAlternateSetting
0x02,        // bNumEndpoints 2
0x08,        // bInterfaceClass
0x06,        // bInterfaceSubClass
0x50,        // bInterfaceProtocol
0x00,        // iInterface (String Index)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x03,        // bEndpointAddress (OUT/H2D)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x84,        // bEndpointAddress (IN/D2H)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

// 116 bytes

5.4.1

0x12,        // bLength
0x01,        // bDescriptorType (Device)
0x00, 0x02,  // bcdUSB 2.00
0xEF,        // bDeviceClass
0x02,        // bDeviceSubClass
0x01,        // bDeviceProtocol
0x40,        // bMaxPacketSize0 64
0x8A, 0x2E,  // idVendor 0x2E8A
0x0A, 0x00,  // idProduct 0x0A
0x00, 0x01,  // bcdDevice 2.00
0x02,        // iManufacturer (String Index)
0x03,        // iProduct (String Index)
0x04,        // iSerialNumber (String Index)
0x01,        // bNumConfigurations 1

0x09,        // bLength
0x02,        // bDescriptorType (Configuration)
0x62, 0x00,  // wTotalLength 98
0x03,        // bNumInterfaces 3
0x01,        // bConfigurationValue
0x00,        // iConfiguration (String Index)
0xA0,        // bmAttributes Remote Wakeup
0x7D,        // bMaxPower 250mA

0x08,        // bLength
0x0B,        // bDescriptorType (Unknown)
0x00, 0x02, 0x02, 0x02, 0x00, 0x00,
0x09,        // bLength
0x04,        // bDescriptorType (Interface)
0x00,        // bInterfaceNumber 0
0x00,        // bAlternateSetting
0x01,        // bNumEndpoints 1
0x02,        // bInterfaceClass
0x02,        // bInterfaceSubClass
0x00,        // bInterfaceProtocol
0x01,        // iInterface (String Index)

0x05,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x00, 0x20, 0x01,
0x05,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x01, 0x00, 0x01,
0x04,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x02, 0x06,
0x05,        // bLength
0x24,        // bDescriptorType (Dependant on Type)
0x06, 0x00, 0x01,
0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x81,        // bEndpointAddress (IN/D2H)
0x03,        // bmAttributes (Interrupt)
0x08, 0x00,  // wMaxPacketSize 8
0x10,        // bInterval 16 (unit depends on device speed)

0x09,        // bLength
0x04,        // bDescriptorType (Interface)
0x01,        // bInterfaceNumber 1
0x00,        // bAlternateSetting
0x02,        // bNumEndpoints 2
0x0A,        // bInterfaceClass
0x00,        // bInterfaceSubClass
0x00,        // bInterfaceProtocol
0x00,        // iInterface (String Index)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x01,        // bEndpointAddress (OUT/H2D)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x82,        // bEndpointAddress (IN/D2H)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

0x09,        // bLength
0x04,        // bDescriptorType (Interface)
0x02,        // bInterfaceNumber 2
0x00,        // bAlternateSetting
0x02,        // bNumEndpoints 2
0x08,        // bInterfaceClass
0x06,        // bInterfaceSubClass
0x50,        // bInterfaceProtocol
0x00,        // iInterface (String Index)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x02,        // bEndpointAddress (OUT/H2D)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

0x07,        // bLength
0x05,        // bDescriptorType (Endpoint)
0x83,        // bEndpointAddress (IN/D2H)
0x02,        // bmAttributes (Bulk)
0x40, 0x00,  // wMaxPacketSize 64
0x00,        // bInterval 0 (unit depends on device speed)

// 116 bytes

And diffs

$ diff /tmp/5.4.1  /tmp/4.7.1 
4,6c4,6
< 0xEF,        // bDeviceClass
< 0x02,        // bDeviceSubClass
< 0x01,        // bDeviceProtocol
---
> 0x00,        // bDeviceClass (Use class information in the Interface Descriptors)
> 0x00,        // bDeviceSubClass
> 0x00,        // bDeviceProtocol
11,13c11,13
< 0x02,        // iManufacturer (String Index)
< 0x03,        // iProduct (String Index)
< 0x04,        // iSerialNumber (String Index)
---
> 0x01,        // iManufacturer (String Index)
> 0x02,        // iProduct (String Index)
> 0x03,        // iSerialNumber (String Index)
36c36
< 0x01,        // iInterface (String Index)
---
> 0x04,        // iInterface (String Index)
69c69
< 0x01,        // bEndpointAddress (OUT/H2D)
---
> 0x02,        // bEndpointAddress (OUT/H2D)
93c93
< 0x02,        // bEndpointAddress (OUT/H2D)
---
> 0x03,        // bEndpointAddress (OUT/H2D)
100c100
< 0x83,        // bEndpointAddress (IN/D2H)
---
> 0x84,        // bEndpointAddress (IN/D2H)

From https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/enumeration-of-the-composite-parent-device we're following the rules they set...

• The device class field of the device descriptor (bDeviceClass) must contain a value of zero, or the class (bDeviceClass), subclass (bDeviceSubClass), and protocol (bDeviceProtocol) fields of the device descriptor must have the values 0xEF, 0x02 and 0x01 respectively, as explained in USB Interface Association Descriptor.
• The device must have multiple interfaces.
• The device must have a single configuration.

[traxanos]

I'll keep an eye on it for now. Since I've only been aware of the problem since I updated your stack and you tinkered with the USB, it seemed obvious.

I also tested it a few times with the 4.6 stack. But I haven't been able to observe it with that yet.

As I said, I'll keep watching for now.