Slow/Failed Enumeration on Windows 11 and Linux pc when bcdUSB = 0x0200 vs 0x0110 while using MSC dual lun example

[siddhartha993549]

Hi, I am using the TinyUSB MSC Dual-LUN example on a Full-Speed USB device. I have observed an unusual enumeration behavior on Windows 11 and Linux pc.

The only change between the two test cases is the bcdUSB value in the Device Descriptor:

Case 1:

.bcdUSB = 0x0110

• Device enumerates consistently.
• Enumeration completes within 1–2 seconds.
• No issues observed.

Case 2:

.bcdUSB = 0x0200

• Enumeration is significantly slower.
• Enumeration sometimes fails completely.
• The behavior is reproducible.

Additional information:

• USB device operates in Full-Speed mode only.
• Using the TinyUSB MSC Dual-LUN example with minimal modifications.
• Host OS: Windows 11.
• Same hardware, same firmware, same descriptors except for bcdUSB.
• No BOS descriptor is implemented.
• No High-Speed support.

My understanding is that a Full-Speed USB 2.0 device should still be able to advertise bcdUSB = 0x0200.

Are there any known issues or additional descriptor requirements when using bcdUSB = 0x0200 in TinyUSB?

Could Windows be sending additional requests (such as Device Qualifier or other USB 2.0-specific requests) that need to be handled differently compared to bcdUSB = 0x0110?

[HiFiPhile]

Using the TinyUSB MSC Dual-LUN example with minimal modifications.

What have you modified ?

With bcdUSB=0x0200 the host will send device qualifier request, for FS-only device just stall it (managed by default).

As you can see stock msc_dual_lun example also use 0x0200 as bcdUSB, below is output using TM4C1294 (musb):

[siddhartha993549]

Hi @HiFiPhile, Thank you for helping.

I am currently using tinyusb version 0.18.0

Please find that attached files that I am using in this example.

The value of BCD here I have updated to 0x110 if I change this to 0x200 then enumeration takes so much time 20-30 seconds and most of the time it fails.

Please let me know if you see any concern in the implementation.

main.c
usb_descriptor.c
msc_disk_dual.c

Tusb config .h file content:

/*

• The MIT License (MIT)
• Copyright (c) 2019 Ha Thach (tinyusb.org)
• Permission is hereby granted, free of charge, to any person obtaining a copy
• of this software and associated documentation files (the "Software"), to deal
• in the Software without restriction, including without limitation the rights
• to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
• copies of the Software, and to permit persons to whom the Software is
• furnished to do so, subject to the following conditions:
• The above copyright notice and this permission notice shall be included in
• all copies or substantial portions of the Software.
• THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
• IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
• FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
• AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
• LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
• OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
• THE SOFTWARE.

*/

#ifndef TUSB_CONFIG_H
#define TUSB_CONFIG_H

#ifdef __cplusplus
extern "C" {
#endif

//--------------------------------------------------------------------+
// Board Specific Configuration
//--------------------------------------------------------------------+

// RHPort number used for device can be defined by board.mk, default to port 0
#ifndef BOARD_TUD_RHPORT
#define BOARD_TUD_RHPORT 0
#endif

// RHPort max operational speed can defined by board.mk
#ifndef BOARD_TUD_MAX_SPEED
#define BOARD_TUD_MAX_SPEED OPT_MODE_DEFAULT_SPEED
#endif

//--------------------------------------------------------------------
// COMMON CONFIGURATION
//--------------------------------------------------------------------

// defined by board.mk
#ifndef CFG_TUSB_MCU
#error CFG_TUSB_MCU must be defined
#endif

#ifndef CFG_TUSB_OS
#define CFG_TUSB_OS OPT_OS_NONE
#endif

#ifndef CFG_TUSB_DEBUG
#define CFG_TUSB_DEBUG 0
#endif

// Enable Device stack
#define CFG_TUD_ENABLED 1

// Default is max speed that hardware controller could support with on-chip PHY
#define CFG_TUD_MAX_SPEED BOARD_TUD_MAX_SPEED

/* USB DMA on some MCUs can only access a specific SRAM region with restriction on alignment.

• Tinyusb use follows macros to declare transferring memory so that they can be put
• into those specific section.
• e.g
• • CFG_TUSB_MEM SECTION : attribute (( section(".usb_ram") ))
• • CFG_TUSB_MEM_ALIGN : attribute ((aligned(4)))
    */
    #ifndef CFG_TUSB_MEM_SECTION
    #define CFG_TUSB_MEM_SECTION
    #endif

#ifndef CFG_TUSB_MEM_ALIGN
#define CFG_TUSB_MEM_ALIGN attribute ((aligned(4)))
#endif

//--------------------------------------------------------------------
// DEVICE CONFIGURATION
//--------------------------------------------------------------------

#ifndef CFG_TUD_ENDPOINT0_SIZE
#define CFG_TUD_ENDPOINT0_SIZE 64
#endif
//------------- CLASS -------------//
#define CFG_TUD_CDC 0
#define CFG_TUD_HID 0
#define CFG_TUD_AUDIO 0
#define CFG_TUD_MSC 1
#define CFG_TUD_BILLBOARD 0

// CDC FIFO size of TX and RX
// MSC Endpoint transfer buffer size
#define CFG_TUD_MSC_EP_BUFSIZE 64

#ifdef __cplusplus
}
#endif

#endif /* TUSB_CONFIG_H */

[HiFiPhile]

Are you still working on musb ? There are quite changes merged, you will have more chance with latest master.

[siddhartha993549]

Yes @HiFiPhile, I am in between of a project so don't want to update anything unless it's very critical. I take all the updates once I finished the current project.

[HiFiPhile]

Yes @HiFiPhile, I am in between of a project so don't want to update anything unless it's very critical. I take all the updates once I finished the current project.

I think it's worth to take latest dcd_musb.c/.h, the fix concern control transfer race could happen when CPU load is high.

[siddhartha993549]

Sure @HiFiPhile , I can try to incorporate atleast musb file changes.

Thank you!!