hathach / tinyusb

An open source cross-platform USB stack for embedded system
https://www.tinyusb.org
MIT License
4.97k stars 1.04k forks source link

"Set Address failed" error on Windows #435

Open aauer1 opened 4 years ago

aauer1 commented 4 years ago

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:

  1. Start the STM32 board with the webusb_serial example
  2. Connect the board over USB to some USB 3.0 host port on a Windows 10 machine
  3. In the device manager the device should be visible with some "set address failed" error. Windows shows also an error popup message.
hathach commented 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

aauer1 commented 4 years ago

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?

aauer1 commented 4 years ago

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.

aauer1 commented 4 years ago

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?

hathach commented 4 years ago

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.

aauer1 commented 4 years ago

I think I'm using the latest version of windows 10. It is Windows 10 Pro Version: 2004 Build Number: 19041.2020

hathach commented 4 years ago

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 ?

aauer1 commented 4 years ago

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.

MimitechIndustries commented 3 years ago

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.

MatiMcFly commented 2 years ago

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.

hathach commented 2 years ago

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.

MatiMcFly commented 2 years ago

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.

JonnyHaystack commented 2 years ago

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

dmalnati commented 7 months ago

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.

Basic Code Structure

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)
};

When 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 image

When 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 image

Here is what wireshark shows image

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.

Other Tests

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.

Other implementations

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.

Final thoughts

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

dmalnati commented 7 months ago

I am adding the #define CFG_TUSB_DEBUG 3 logging for the both scenarios above (I hadn't realized I could enable this before).

Diff between 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?

image

Scenario where 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

Scenario where 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