Adafruit Feather M0 Express - A request for the USB device descriptor failed.

[gojimmypi]

Describe the bug

Adafruit Feather M0 Express fails to enumerate and initialize as a valid USB device when a (potentially*) misbehaving other USB device is also plugged in concurrently to the same external hub. This issue opened in this repo after a long and winding tweet thread ended with @tannewt suggesting I open an issue here.

(*) I have no proof that the other device (a fomu in this case) is actually misbehaving, although @smunaut did make a comment about having seen "people taking quite a few non-compliant shortcuts with USB implementations" and admittedly the fomu is not an ordinary device. ;)

Both the fomu and Feather M0 are completely happy and operational when not plugged into the same external hub.

Set up (please complete the following information):

• OS: Windows 10 1909 [Version 10.0.18363.657]

• Board: Adafruit Feature M0 Express

• Firmware Code: TBD

• Board: fomu with Fomu DFU Bootloader v1.8.7

• Firmware Code: TBD

To Reproduce

Steps to reproduce the behavior:

1) Plug a fomu - hacker version into an Amazon Basics USB hub. Note is a fully functional fomu, that has no apparent problems of its own.

2) (optional) Being so tiny, perhaps even forget that the fomu is plugged into the other side of the hub. This adds so much fun to the mystery. I initially thought the problem was hub-specific, until I later noticed the fomu tucked into place on the other side. I later confirmed this problem also occurs on a completely different hub, such as the ICZI USB 3.0

3) Plug in the Adafruit M0. into the same USB hub.

4) Note that Windows complains that:

           USB Device Not Recognized
           The last USB device you connected
           to this computer malfunctioned, and
           Windows does not recognize it 

5) It should be noted that other USB devices, such as a mouse and Saleae logic analyzer capturing at full speed are otherwise operational and fully functional when following these steps and plugged into the same hub.

Expected behavior

I would have expected the Feather M0 to work properly, even if the fomu was misbehaving*

Screenshots

The fomu in place:

Device Manager:

Wireshark:

Additional context

I started down this path with the desire to get my ULX3S working with Circuit Python. I have a (not yet published) blog with those details, but in the meantime I have some files that may be helpful.

I also have a pair of USB breakout boards to capture the initialization with my Saleae logic analyzer, per a suggestion from @smunaut if anyone would like to look.

cc: @PaulStoffregen

[hathach]

@gojimmypi thank you for filing the detailed issue. This is indeed right place since both FOMU and M0 running TinyUSB stack. I happens to have an FOMU as well, though I need your help to with the firmware:

1. What is your FOMU bitstream, the latest bitstream with eptri did fix some usb hw issue
2. your FOMU firmware, any hex/elf file is appreciated
3. An uf2 for M0 that you are having issue with

I don't have amazon basic hub, hopefully most hub is pretty much the same, I will try with one I have.

[gojimmypi]

@hathach thanks for looking into this.

First - the problem does not seem to be specific to a hub. In addition to the budget USB2 hub, I am seeing the same results with an external USB3 hub. But it is only with hubs: I can plug each device into separate ports on my computer and the problem does not occur.

1. What is your FOMU bitstream, the latest bitstream with eptri did fix some usb hw issue

I'm not sure on the fomu bitstream. Is there a way I can determine this? If you are referring to ./foboot-bitstream.py then I didn't send anything to my fomu yet

2. your FOMU firmware, any hex/elf file is appreciated

other than the dfu-util details?

Found DFU: [1209:5bf0] ver=0101, devnum=13, cfg=1, intf=0, path="1-1.3", alt=0, name="Fomu DFU Bootloader v1.8.7", serial="UNKNOWN"

I believe I left off after the teardown2019-workshop so that file is probably what's on there now.

3. An uf2 for M0 that you are having issue with

I believe the uf2 for the M0 I downloaded on March 1, and is adafruit-circuitpython-feather_m0_express-en_US-4.1.2.uf2

When working properly (without the fomu)... I connect to the COM port for Circuit Python, I see:

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.

Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 4.1.2 on 2019-12-18; Adafruit Feather M0 Express with samd21g18
>>>

I also found a update-bootloader-metro_m0-v3.7.0.uf2 file in my downloads, but I didn't leave myself enough notes to recall what I did with it. :/ I was following along with one of the Adafruit tutorials so it was probably the one from here as noted a bit further down the page.

Does this help? Otherwise please detail instructions :) cheers

[hathach]

@hathach thanks for looking into this.

First - the problem does not seem to be specific to a hub. In addition to the budget USB2 hub, I am seeing the same results with an external USB3 hub. But it is only with hubs: I can plug each device into separate ports on my computer and the problem does not occur.

1. What is your FOMU bitstream, the latest bitstream with eptri did fix some usb hw issue

I'm not sure on the fomu bitstream. Is there a way I can determine this? If you are referring to ./foboot-bitstream.py then I didn't send anything to my fomu yet

1. your FOMU firmware, any hex/elf file is appreciated

other than the dfu-util details?

Found DFU: [1209:5bf0] ver=0101, devnum=13, cfg=1, intf=0, path="1-1.3", alt=0, name="Fomu DFU Bootloader v1.8.7", serial="UNKNOWN"

I believe I left off after the teardown2019-workshop so that file is probably what's on there now.

1. An uf2 for M0 that you are having issue with

I believe the uf2 for the M0 I downloaded on March 1, and is adafruit-circuitpython-feather_m0_express-en_US-4.1.2.uf2

When working properly (without the fomu)... I connect to the COM port for Circuit Python, I see:

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.

Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 4.1.2 on 2019-12-18; Adafruit Feather M0 Express with samd21g18
>>>

I also found a update-bootloader-metro_m0-v3.7.0.uf2 file in my downloads, but I didn't leave myself enough notes to recall what I did with it. :/ I was following along with one of the Adafruit tutorials so it was probably the one from here as noted a bit further down the page.

Does this help? Otherwise please detail instructions :) cheers

Yes, it very helpful, I will try to reproduce the issue as soon as I could. Though to be honest, I am also newbie with FPGA and FOMU as well. I will need to spend sometime to get started with it first. Hopefully it is easy to reproduce :) . I will ping you for more update :+1:

[smunaut]

As I mentioned on twitter, that fomu bitstream version has a known bug where it doesn't check the address field of USB packets and just responds to all of them. That bug is fixed in newer version of the bitstream.

That is known to cause issues for other devices on the same hub and AFAIK there is nothing the other devices can do about it if some other device answers requests that are not meant for them ...

[gojimmypi]

Yes, I completely agree that this could be fixed with a fomu that is not misbehaving. Using a different USB port also works for me as a workaround.

However I thought it was curious that only the Feather M0 had problems. Other devices including my mouse in operation and the Saleae logic analyzer capturing packets, could both be on the same hub with the fomu and work properly. What's different about the Feather?

I thought perhaps if the Feather M0 could somehow tolerate the fomu misbehaving, then other users might avoid a similar frustration.

[smunaut]

The Saleae is USB High Speed. Completely different thing.

Not sure about the mouse but maybe it's Low Speed, or maybe it's also High Speed, you'd have to check. (and so would also be in another "domain").

[PaulStoffregen]

Another possible (blind guess) explanation could involve a race condition involving the time each device takes to begin its response, especially if the hub has a single transaction translator. When connected to a hub, low and full speed devices don't communicate directly with the host. They talk to the the hub's TT, which slowly retransmits the split-start packet it received from the host at 480 Mbit/sec, then waits for a device to slowly respond, which the host later reads at 480 speed with split-complete. If 2 devices respond, very likely the 1st to begin its response triggers logic inside the TT to receive only from that port.

While a mouse is almost certainly a low speed device, it is probably made from dedicated hardware which has no software overhead involved in its response time.

High speed 480 Mbit/sec devices are handled without a TT. A special chirp sequence during the reset time is used to detect whether high speed is connected on that port. High speed communication is routed only to downstream ports which responded to the chirp, avoiding any conflict with full and low speed devices which are serviced by the transaction translator(s) on the ports which didn't chirp.

[PaulStoffregen]

If you have a moment, I'd be curious to know whether that hub is a Single TT or Multi TT type. If you have even more time, would be interesting to know if using the other type of hub makes any difference?

To check your hub, in Linux use "lsusb -v" and look for these bDeviceProtocol lines. Hubs with only 1 transaction translator shared by all downstream ports have bDeviceProtocol = 1.

  bDeviceProtocol         1 Single TT

Multi-TT hubs have

  bDeviceProtocol         2 TT per port

On Windows 10, you can check your hub's protocol in the Windows Device Manager properties "Advanced" tab.

[gojimmypi]

lsusb -v is completely empty in WSL on Windows 10 and the hubs do not appear to be attachable devices in my Ubuntu VM,

This issue occurs for both of my hubs (USB2 and USB3) although I've been unable to determine TT Device Protocol you ask about.

For the USB3 hub:

In Windows, it appears that I get two devices: a Generic SuperSpeed USB hub and a Generic USB Hub.

Before:

After:

I don't seem to have an Advanced tab; yours appears to be missing the Events tab:

I do however, have a new symptom. I've since rebooted after first opening this issue. The Feather now appears as a second fomu device when plugged in after the fomu,

If I plug the Feather in on its own, it works fine. If I later plug in the fomu to the hub as well, the Feather stops functioning properly and again appears as an error with Descriptor Request Failed.

I learned about Device Ranking

The Feather:

The Feather appears to show up as 3 controllers and a COM port.

It is all pretty weird. Would you like to continue investigating?

[PaulStoffregen]

Did you update your Fomu with the latest bitstream? If that fully resolves this problem, probably best to close this issue.

While I'm always curious to learn more of the hidden details of how hubs and other USB hardware really work internally, I really do not believe there's much more to be gained here looking through the lens of Windows enumeration results and Windows Device Manager.

[gojimmypi]

Sorry for the delay in responding. Between the day job, and helping to launch the ULX3S... well, time just flies by!

While I'm always curious to learn more of the hidden details of how hubs and other USB hardware really work internally, I really do not believe there's much more to be gained here looking through the lens of Windows enumeration results and Windows Device Manager.

@PaulStoffregen I too, am always curious to learn more! I have 2 USB breakout devices and a Saleae logic analyzer if you or anyone else is interested in digging further.

Otherwise... Yes: updating my Fomu with hacker-updater-v2.0.3.dfu resolved the problem with the Feather M0:

C:\Download\dfu-util>dfu-util -D fomu\hacker-updater-v2.0.3.dfu
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 1209
Match product ID from file: 70b1
Opening DFU capable USB device...
ID 1209:5bf0
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [=========================] 100%       112828 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

C:\Download\dfu-util>dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1209:5bf0] ver=0101, devnum=10, cfg=1, intf=0, path="1-1.3", alt=0, name="Fomu Hacker running DFU Bootloader v2.0.3", serial="UNKNOWN"

Both the fomu and Feather M0 appear to be happy together on a hub now:

If you'd like me to proceed - let me know, otherwise feel free to close this issue.

[gojimmypi]

update: although not specific to the Feather M0 and there's no observable problem... there's certainly this curiosity for just the fomu:

Note that despite dfu-util reporting version 2.0.3 of the bootloader, Windows device manager claims it is still 1.8.7.

This condition persists after disconnecting the fomu, rebooting, and re-plugging in the fomu. (no Feather plugged in at all)

[hathach]

Hi all, sorry I was too buy with ESP32-S2 port. Just pull out my fomu and flash the latest bootloader v2.0.3. And as @smunaut said, the bug is in valentyUSB core and is fixed with latest bootloader. I think this issue should be closed now.

@gojimmypi Maybe windows cache it or something. On linux with lsusb the string is correct said 2.0.3

$ lsusb -v -d 1209:

Bus 001 Device 110: ID 1209:5bf0 InterBiometrics 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.01
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x1209 InterBiometrics
  idProduct          0x5bf0 
  bcdDevice            1.01
  iManufacturer           1 Foosn
  iProduct                2 Fomu PVT running DFU Bootloader v2.0.3
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           27
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          1 Foosn
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
      bInterfaceSubClass      1 Device Firmware Update
      bInterfaceProtocol      2 
      iInterface              2 Fomu PVT running DFU Bootloader v2.0.3
      Device Firmware Upgrade Interface Descriptor:
        bLength                             9
        bDescriptorType                    33
        bmAttributes                       13
          Will Detach
          Manifestation Tolerant
          Upload Unsupported
          Download Supported
        wDetachTimeout                  10000 milliseconds
        wTransferSize                    4096 bytes
        bcdDFUVersion                   1.01

[gojimmypi]

@hathach yes, the fomu update fixed the problem for me. But the issue was more if there was something in the Feather M0 that allowed the problem caused by the fomu to manifest: perhaps symptomatic of some other vulnerability or problem on the Feather?

Updating fomu software to fix a problem observed on the Feather M0 seems to me intuitively unwise to label as "fixed". In my experience, this stuff usually comes back to bite again.

[hathach]

@hathach yes, the fomu update fixed the problem for me. But the issue was more if there was something in the Feather M0 that allowed the problem caused by the fomu to manifest: perhaps symptomatic of some other vulnerability or problem on the Feather?

Updating fomu software to fix a problem observed on the Feather M0 seems to me intuitively unwise to label as "fixed". In my experience, this stuff usually comes back to bite again.

It is indeed the fomu issue, USB is a shared-bus like I2C. Each packet has an address, device should only response to packet with the same address. FOMU valentyUSB controller in the old version didn't check the address field of the packet, and response to all the requests (probably since it is tested as the single device attached). It has nothing to do with M0, the data just got corrupted by 2 devices responded concurrently. So yeah, it think it is safe to close this now.

[gojimmypi]

it was curious that only the Feather had problems as noted above, with other devices working properly. I wonder what made them more tolerant to a misbehaving neighbor, and why was the M0 not similarly tolerant?

Admittedly this is probably a rather remote corner case, so I agree to close.

[PaulStoffregen]

I wonder what made them more tolerant to a misbehaving neighbor

Scroll up to March 9 and re-read my comment about latency and transaction translators.

[hathach]

Thank you everyone for a helpful discussion on this issue