Open aauer1 opened 4 years ago
"basically the same" is not good enough, please run the exact stock example and, if possible with one of the official dev board. the condition for reproduce is already ambiguous enough. Also please provide the debug log and/or bus capture, it would help others to analyse without actually reproducing the issue
I modified my setup and now I'm running the exact webusb_serial stock example. The result is the same. The device is not working under Windows 10 when it is connected to an USB 3.0 port. I also captured the log output:
USBD Bus Reset USBD Setup Received 80 06 00 01 00 00 40 00 Get Descriptor Device Queue EP 80 with 18 bytes USBD Xfer Complete on EP 80 with 18 bytes Queue EP 00 with zlp Status USBD Xfer Complete on EP 00 with 0 bytes USBD Bus Reset USBD Setup Received 80 06 00 01 00 00 40 00 Get Descriptor Device Queue EP 80 with 18 bytes USBD Xfer Complete on EP 80 with 18 bytes Queue EP 00 with zlp Status USBD Xfer Complete on EP 00 with 0 bytes USBD Bus Reset USBD Setup Received 80 06 00 01 00 00 40 00 Get Descriptor Device Queue EP 80 with 18 bytes USBD Xfer Complete on EP 80 with 18 bytes Queue EP 00 with zlp Status USBD Xfer Complete on EP 00 with 0 bytes USBD Bus Reset USBD Setup Received 80 06 00 01 00 00 40 00 Get Descriptor Device Queue EP 80 with 18 bytes USBD Xfer Complete on EP 80 with 18 bytes Queue EP 00 with zlp Status USBD Xfer Complete on EP 00 with 0 bytes USBD Suspend
On an USB 2.0 port the log output looks like this:
USBD Bus Reset USBD Setup Received 80 06 00 01 00 00 40 00 Get Descriptor Device Queue EP 80 with 18 bytes USBD Xfer Complete on EP 80 with 18 bytes Queue EP 00 with zlp Status USBD Xfer Complete on EP 00 with 0 bytes USBD Bus Reset USBD Setup Received 00 05 0D 00 00 00 00 00 Set Address USBD Xfer Complete on EP 80 with 0 bytes USBD Setup Received 80 06 00 01 00 00 12 00 Get Descriptor Device Queue EP 80 with 18 bytes USBD Xfer Complete on EP 80 with 18 bytes Queue EP 00 with zlp Status USBD Xfer Complete on EP 00 with 0 bytes
So, the communication is starting the same way. But after the first transfer an "USBD Bus Reset" is logged. On USB 3.0 it starts over again and starts with the same "Get Descriptor Device" request. On the USB 2.0 port, it is setting the address correctly.
But why is this happening? Is it normal that a Bus reset is happening after the first descriptor request?
I tested another example. I used the "hid_generic_inout". And this one works!
USBD init HID init USBD Bus Reset USBD Bus Reset USBD Setup Received 80 06 00 01 00 00 40 00 Get Descriptor Device Queue EP 80 with 18 bytes USBD Xfer Complete on EP 80 with 18 bytes Queue EP 00 with zlp Status USBD Xfer Complete on EP 00 with 0 bytes USBD Bus Reset USBD Setup Received 00 05 16 00 00 00 00 00 Set Address USBD Xfer Complete on EP 80 with 0 bytes USBD Setup Received 80 06 00 01 00 00 12 00 Get Descriptor Device Queue EP 80 with 18 bytes
This is really strange. As you can see, after the bus reset, I get an address assigned. Has anyone a clue what may be the problem here.
I tried to figure out what's the difference between examples which are working and the webusb example which is not working. And I found out, that if I change the bcdUSB version number in the device descriptor to 0x0200, the device gets enumerated and the "Set Address failed" error is gone.
So, what's the difference between bcdUSB 0x0210 and 0x0200? Would the webUSB stuff also work with bcdUSB set to 0x0200 instead of 0x0210? Because the comment in the code is telling me that it needs to be "at least 2.1 or 3.x for BOS & webUSB"?! Is that true?
So, what's the difference between bcdUSB 0x0210 and 0x0200? Would the webUSB stuff also work with bcdUSB set to 0x0200 instead of 0x0210? Because the comment in the code is telling me that it needs to be "at least 2.1 or 3.x for BOS & webUSB"?! Is that true?
BCD = 2.1 will trigger host to request BOS descriptors, windows will go further to also request MS OS 2.0 descriptor https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-os-2-0-descriptors-specification which is needed for WebUSB. in your 1st log, host indeed doesn't attempt to Set Address at all, maybe the device descriptor does not make sense. Can you try with another PC with 3.0 port, maybe windows driver somehow expect device to have at least highspeed with 2.1, I am not sure, please also update your 1st port with windows build number as well. I am on Linux, so my help is limited, but other windows user could help.
PS: it can be racing condition as well, it is hard to know without a usb analyzer, though you can also try to capture the bus data with wireshark as well. It will definitely help to analyze the problem.
I think I'm using the latest version of windows 10. It is Windows 10 Pro Version: 2004 Build Number: 19041.2020
I think I'm using the latest version of windows 10. It is Windows 10 Pro Version: 2004 Build Number: 19041.2020
Could you be able to reproduce this on another machine with USB 3.0 port ?
Yes, I was able to reproduce the same error on two other windows 10 machines. But I don't know the exact version and build number of them. BTW with windows 7 on the very same machine and the same USB 3.0 port it works fine. I think somehow the windows 10 USB 3 driver is different. I also tested to set bcdUSB version to 0x0200 and manually install the winusb driver with zadig. This workaround seems to work at least on my machine. I will test this on another machine tomorrow.
I can confirm that I had this issue as well, setting bcdUSB to 0x0200 is what I'm doing as well now to get around it. I have an analyzer and will look into this more in depth if I get time to. For reference, I am using an STM32H750 with a USB3300 ULPI PHY.
I am experiencing the exact same problem. Is there already a workaround available that doesn't involve fiddling around with drivers?
I'm trying to implement a composite device that has RNDIS capabilities and a serial interface. This works fine as long as I only provide one configuration descriptor. As soon as I add a second configuration (for CDC_ECM support since Mac OSX devices don't support RNDIS), my windows PC will only pick the very first interface it sees in a descriptor.
After doing some googling I concluded that I need to provide a BOS descriptor for Windows to tell it to use all available interfaces contained in the first configuration. However, when I change bcdUSB to 0x0210, enumeration fails entirely under Windows.
On a side note: Using my Ubuntu system, any combination/order of the descriptors work fine. There I can also change the bcdUSB version without getting into any trouble.
It seems that windows 10 decides that our descriptors aren't correct and refuse to proceed with enumerate. I still haven't tried this out
@MatiMcFly your issue is different, in this issue, device isn't got it address assigned yet. Double check your descriptor, length, type etc... You could create your own issue with detail of setup/code/log for reproducing/troubleshooting.
Since setting up a new project takes some time, I decided to look further into the composition of my descriptors. I am sure they contain correct data since I checked them multiple times.
The only real difference is that in the device descriptor I set .bcdUSB = 0x0210
or .bcdUSB = 0x0200
respectively.
Here is some log output which hopefully helps with understanding my issue:
.bcdUSB = 0x02100
(not working):
bcdUSB_0x0210.txt
I noted that after the reset in line 53 the startup behavior seems to repeat itself. I cannot explain this.
.bcdUSB = 0x0200
(working)*:
bcdUSB_0x0200.txt
In this log file, we can see that the enumeration seems to work since the endpoints for actual communication are opened in lines 92 and onwards.
side note: by working I mean that the device gets enumerated. Of course, Windows only detects one of the two interfaces present in the very first configuration. Therefore I need to provide the Windows BOS headers in order to have it read all my available interfaces.
Edit: the logs have all been acquired on a USB 3.0 port. I could also provide logs for a Linux machine as well as logs for a USB 2.0 port.
Setting bcdUSB to 0x0210 also causes enumeration to fail on RP2040 it seems. 0x0200 works there too, but it means BOS/MS OS descriptors won't be requested 😔
EDIT: Actually I just tried the webusb_serial example and that works..? I was trying to do it through the Adafruit TinyUSB library if that makes any difference, but I wouldn't have expected it to...
EDIT 2: Okay did some debugging and my problem seems to be specific to Adafruit TinyUSB so I'll make an issue over there
Hi, adding a few details here since this is impacting me as well.
Computer: Windows 11 version 22H2 build 22621.3007 Microcontroller:
Like others, a change from bcdUSB = 0x0200
to bcdUSB = 0x0210
makes the device no longer enumerate on my PC. I don't have any different computers to try this on.
Here is the basic code structure, which nearly matches example implementations. (I see known good examples are already understood to be not working for RP2040 so I haven't tried to reproduce that).
static tusb_desc_device_t desc_device =
{
.bLength = sizeof(tusb_desc_device_t),
.bDescriptorType = TUSB_DESC_DEVICE,
.bcdUSB = 0x0200,
// Use Interface Association Descriptor (IAD) for CDC
// As required by USB Specs IAD's subclass must be
// common class (2) and protocol must be IAD (1)
.bDeviceClass = TUSB_CLASS_MISC,
.bDeviceSubClass = MISC_SUBCLASS_COMMON,
.bDeviceProtocol = MISC_PROTOCOL_IAD,
.bMaxPacketSize0 = CFG_TUD_ENDPOINT0_SIZE,
.idVendor = 0,
.idProduct = 0,
.bcdDevice = 0,
.iManufacturer = 0x01,
.iProduct = 0x02,
.iSerialNumber = 0x03,
.bNumConfigurations = 0x01
};
enum
{
ITF_NUM_CDC = 0,
ITF_NUM_CDC_DATA,
ITF_NUM_VENDOR,
ITF_NUM_TOTAL
};
...
inline static vector<string> strList_ = {
"Manufacturer",
"Product",
"",
"CDC Interface",
"Vendor Interface",
};
#define EPNUM_CDC_NOTIF 0x81
#define EPNUM_CDC_OUT 0x02
#define EPNUM_CDC_IN 0x82
#define EPNUM_VENDOR_OUT 0x03
#define EPNUM_VENDOR_IN 0x83
#define CONFIG_TOTAL_LEN (TUD_CONFIG_DESC_LEN + TUD_CDC_DESC_LEN + TUD_VENDOR_DESC_LEN)
static uint8_t const desc_fs_configuration[] =
{
// Config number, interface count, string index, total length, attribute, power in mA
TUD_CONFIG_DESCRIPTOR(1, ITF_NUM_TOTAL, 0, CONFIG_TOTAL_LEN, 0x00, 100),
// Interface number, string index, EP notification address and size, EP data address (out, in) and size.
TUD_CDC_DESCRIPTOR(ITF_NUM_CDC, 4, EPNUM_CDC_NOTIF, 8, EPNUM_CDC_OUT, EPNUM_CDC_IN, 64),
// Interface number, string index, EP Out & IN address, EP size
TUD_VENDOR_DESCRIPTOR(ITF_NUM_VENDOR, 5, EPNUM_VENDOR_OUT, EPNUM_VENDOR_IN, 64)
};
bcdUSB = 0x0200
When bcdUSB = 0x0200
, it works as expected.
Here are the events the microcontroller sees:
Device Descriptor (tud_descriptor_device_cb)
Device Descriptor (tud_descriptor_device_cb)
Config Descriptor (tud_descriptor_configuration_cb)
String Descriptor 3 (tud_descriptor_string_cb)
String Descriptor 0 (tud_descriptor_string_cb)
String Descriptor 2 (tud_descriptor_string_cb)
Device Descriptor (tud_descriptor_device_cb)
Config Descriptor (tud_descriptor_configuration_cb)
Config Descriptor (tud_descriptor_configuration_cb)
Config Descriptor (tud_descriptor_configuration_cb)
USB Mounted (tud_mount_cb)
...
Here is what usbview shows
bcdUSB = 0x0210
When bcdUSB = 0x0210
, the device fails to enumerate.
Here are the events the microcontroller sees:
Device Descriptor (tud_descriptor_device_cb)
Device Descriptor (tud_descriptor_device_cb)
Config Descriptor (tud_descriptor_configuration_cb)
Device Descriptor (tud_descriptor_device_cb)
Device Descriptor (tud_descriptor_device_cb)
Config Descriptor (tud_descriptor_configuration_cb)
Device Descriptor (tud_descriptor_device_cb)
Device Descriptor (tud_descriptor_device_cb)
Config Descriptor (tud_descriptor_configuration_cb)
Device Descriptor (tud_descriptor_device_cb)
Device Descriptor (tud_descriptor_device_cb)
Config Descriptor (tud_descriptor_configuration_cb)
USB Suspended
Here is what usbview shows
Here is what wireshark shows
I don't know how the wireshark captures work at a low level, but I'm not very confident it's correct. It's showing all zero bytes, which unlikely but I don't know, but also it just doesn't have all the events my microcontroller sees, so at a minimum some events are missing.
I tried plugging this device in to some daisy-chained USB ports, as well as to the motherboard port of USB 3.0 and USB 2.0 ports directly on the computer, the effect is always the same when the device fails to enumerate.
I tried building the application against the latest mainline version of tinyusb and that did not change anything.
There is a youtube video from stacksmashing showing that this USB 2.1 functionality worked at one point in the past. The github (link) for the firmware shows materially similar functionality to what I (and others) have, so I wonder if there was a regression between then (2021) and now for the RP2040.
The stacksmashing firmware was committed in May 2021. I tried building that code against the tinyusb repo of that time, as well as the tinyusb repo contained within the pico-sdk at the time. I had to change, for example, the tud_vendor_control_request_cb
function to tud_vendor_control_xfer_cb
, to get it to compile in some cases. In others clearly the libraries were out of sync. I don't know what version of tinyusb this guy was building against for certain and I don't think there is a good way to know without asking him.
Regardless, though, his video shows that in 2021, on the pico-sdk w/ tinyusb (no FreeRTOS), the bcdUSB = 0x0210
was working.
Hope this set of observations helps.
I would love to be able to make use of the features available with USB 2.1 and if there is anything more I can do to help investigate this please let me know.
Thanks.
Doug
I am adding the #define CFG_TUSB_DEBUG 3
logging for the both scenarios above (I hadn't realized I could enable this before).
bcdUSB = 0x0200
and bcdUSB = 0x0210
This image is the first of 4 sequences of the same pattern.
It is showing that in the bcdUSB = 0x0210
case, the BUS RESET
and USBD Bus Reset : Full Speed
don't occur, also that the USBD Setup Received
bytes change from 00 05 31 ...
to 00 05 25 ...
, but I don't know the significance of this. Perhaps a lead into root cause?
bcdUSB = 0x0200
Full output:
USBD init on controller 0
sizeof(usbd_device_t) = 83
sizeof(tu_fifo_t) = 20
sizeof(tu_edpt_stream_t) = 116
CDC init
VENDOR init
sizeof(hw_endpoint_t) = 32
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
BUS RESET
USBD Xfer Complete on EP 00 with 0 bytes
USBD Bus Reset : Full Speed
USBD Setup Received 00 05 31 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
BUS RESET
USBD Xfer Complete on EP 00 with 0 bytes
USBD Bus Reset : Full Speed
USBD Setup Received 00 05 32 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
BUS RESET
USBD Xfer Complete on EP 00 with 0 bytes
USBD Bus Reset : Full Speed
USBD Setup Received 00 05 33 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
BUS RESET
USBD Xfer Complete on EP 00 with 0 bytes
USBD Bus Reset : Full Speed
USBD Setup Received 00 05 34 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
USBD Suspend : Remote Wakeup = 0
bcdUSB = 0x0210
Full output:
USBD init on controller 0
sizeof(usbd_device_t) = 83
sizeof(tu_fifo_t) = 20
sizeof(tu_edpt_stream_t) = 116
CDC init
VENDOR init
sizeof(hw_endpoint_t) = 32
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
USBD Xfer Complete on EP 00 with 0 bytes
USBD Setup Received 00 05 25 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
USBD Xfer Complete on EP 00 with 0 bytes
USBD Setup Received 00 05 26 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
USBD Xfer Complete on EP 00 with 0 bytes
USBD Setup Received 00 05 27 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes ...
Prepare BufCtrl: [0] = 0xf412 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6012 [1] = 0x0000
Short packet on buffer 0 with 18 bytes
Completed transfer of 18 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with 0 bytes ...
Prepare BufCtrl: [0] = 0x7400 [1] = 0x0000
buf_status = 0x00000002
Sync BufCtrl: [0] = 0xe000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 out
USBD Xfer Complete on EP 00 with 0 bytes
USBD Setup Received 00 05 28 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
USBD Suspend : Remote Wakeup = 0
Set up
Describe the bug What I have recognized is that at least on Windows 10 the device is not correctly enumerated. When I attach the device to the Windows 10 host, the device gets disabled and in the device manager I see "Set Address failed" error message. The strange thing is this is not happening on all USB ports. I only see this problem on USB 3.0 ports. If I connect it to an USB 2.0 port on the same PC it works just fine. Additionally, this error doesn't happen e.g. on Ubuntu 20.04 (I tested it on the same host on the same port). As mentioned above, I'm basically using the webusb_serial example. But I added it to my own simple application code. Maybe someone could probably run the original webusb_serial example on some stm32 board.
What could be the problem here? Has anybody an idea where to start looking to solve this problem? Could it be some kind of timing problem on USB 3.0 ports caused by the Windows driver?!
To reproduce Steps to reproduce the behavior: