0
\$\begingroup\$

TLDR: Can USB packets be transmitted between host and device, even if a possible hardware problem exists as evidenced by a USB error -71?

I am working on a custom board that uses USB 2.0 HS to communicate with a host computer. Previously, my computer was able to enumerate my device and start communication--however, upon receiving pre-fabricated copies of my board, enumeration no longer happens, and I'm presented with a USB error -71.

When I plug my device into my computer, dmesg gives the following output:

[ 9058.933325] usb 3-4: new high-speed USB device number 22 using xhci_hcd
[ 9059.061745] usb 3-4: Device not responding to setup address.
[ 9059.269619] usb 3-4: Device not responding to setup address.
[ 9059.481349] usb 3-4: device not accepting address 22, error -71

Many forums that I've visited online blame device- or host-side hardware issues for the error mentioned above. However, this advice doesn't make sense to me in my situation, for reasons to come.

In an effort to debug , I've used Wireshark to capture USB packets being sent between the host and the faulty device. I've even compared the packets from the faulty device to working devices that use the same MCU I use on the board (for instance, a development board for the MCU) and the packets 'agree' up to a certain packet. Here are the outputted packets from Wireshark for the faulty board:

      1 0.000000       3.1.1                 host                  USB      67     URB_INTERRUPT in
      2 0.000012       host                  3.1.1                 USB      64     URB_INTERRUPT in
      3 0.000042       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
      4 0.000087       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
      5 0.000093       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: C_PORT_CONNECTION]
      6 0.000131       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: C_PORT_CONNECTION]
      7 0.000136       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
      8 0.000173       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
      9 0.035198       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     10 0.035252       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     11 0.071208       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     12 0.071301       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     13 0.107180       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     14 0.107227       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     15 0.143176       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     16 0.143225       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     17 0.143337       host                  3.1.0                 USBHUB   64     SET_FEATURE Request    [Port 3: PORT_RESET]
     18 0.143378       3.1.0                 host                  USBHUB   64     SET_FEATURE Response   [Port 3: PORT_RESET]
     19 0.211191       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     20 0.211248       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     21 0.211255       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: C_PORT_RESET]
     22 0.211295       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: C_PORT_RESET]
     23 0.271315       host                  3.0.0                 USB      64     GET DESCRIPTOR Request DEVICE
     24 0.271503       3.0.0                 host                  USB      82     GET DESCRIPTOR Response DEVICE
     25 0.271530       host                  3.1.0                 USBHUB   64     SET_FEATURE Request    [Port 3: PORT_RESET]
     26 0.271592       3.1.0                 host                  USBHUB   64     SET_FEATURE Response   [Port 3: PORT_RESET]
     27 0.339156       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     28 0.339220       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     29 0.339228       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: C_PORT_RESET]
     30 0.339266       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: C_PORT_RESET]
     31 0.815223       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: PORT_ENABLE]
     32 0.815280       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: PORT_ENABLE]
     33 0.815548       host                  3.1.0                 USBHUB   64     SET_FEATURE Request    [Port 3: PORT_RESET]
     34 0.815590       3.1.0                 host                  USBHUB   64     SET_FEATURE Response   [Port 3: PORT_RESET]
     35 0.870742       3.1.1                 host                  USB      67     URB_INTERRUPT in
     36 0.870758       host                  3.1.1                 USB      64     URB_INTERRUPT in
     37 0.883203       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     38 0.883274       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     39 0.927234       3.1.1                 host                  USB      67     URB_INTERRUPT in
     40 0.927243       host                  3.1.1                 USB      64     URB_INTERRUPT in
     41 0.951214       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     42 0.951273       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     43 1.159190       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     44 1.159250       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     45 1.175192       3.1.1                 host                  USB      67     URB_INTERRUPT in
     46 1.175196       host                  3.1.1                 USB      64     URB_INTERRUPT in
     47 1.367190       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     48 1.367251       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     49 1.423167       3.1.1                 host                  USB      67     URB_INTERRUPT in
     50 1.423184       host                  3.1.1                 USB      64     URB_INTERRUPT in
     51 1.575195       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     52 1.575256       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     53 1.575264       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: C_PORT_RESET]
     54 1.575308       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: C_PORT_RESET]
     55 1.575313       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: PORT_ENABLE]
     56 1.575356       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: PORT_ENABLE]
     57 1.575512       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: PORT_ENABLE]
     58 1.575555       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: PORT_ENABLE]
     59 1.575566       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     60 1.575608       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     61 1.575613       host                  3.1.0                 USBHUB   64     CLEAR_FEATURE Request  [Port 3: C_PORT_CONNECTION]
     62 1.575655       3.1.0                 host                  USBHUB   64     CLEAR_FEATURE Response [Port 3: C_PORT_CONNECTION]
     63 1.575663       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     64 1.575704       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     65 1.611188       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     66 1.611251       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     67 1.647156       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     68 1.647212       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     69 1.683213       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     70 1.683272       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]
     71 1.719178       host                  3.1.0                 USBHUB   64     GET_STATUS Request     [Port 3]
     72 1.719229       3.1.0                 host                  USBHUB   68     GET_STATUS Response    [Port 3]

When I compared this output to that of a working development board, I noticed that the transactions take different directions around packet 31, when the host issues a CLEAR_FEATURE Request [Port 3: PORT_ENABLE]. Then it almost looks like the host tries to restart the USB communication with the faulty board all over again, and eventually I get the usb error -71 in dmesg (strangely enough, not in Wireshark).

What I don't understand is something likely very naive: if device not responding to setup address, usb error -71 generally is triggered by a hardware issue, why is my device able to maintain USB communication with my computer as shown above? Wouldn't a hardware issue imply that no USB packets would be able to be sent?

EDIT

A detailed breakdown of the packets I received in the above Wireshark log are included in the following repo:

https://github.com/cosmicchasm/Array_USB_Data

\$\endgroup\$
5
  • \$\begingroup\$ Is there a reason to expect the fabricated boards to work? Do you have MCU or some ASIC for USB? If MCU, is it programmed with firmware? Do chips receive power, do they have working clock, are they out of reset, etc? Can you post schematics? Did you make anything differently in the schematics or in the PCB compared to the working prototype? \$\endgroup\$
    – Justme
    Commented Sep 6 at 21:35
  • \$\begingroup\$ The official development board works, if I understand what you wrote. Your own fabricated boards don't work. (Not sure about that, though, since you also appear to write: "my device [is] able to maintain USB communication".) I assume you are using a software library for the USB communications that you did not write, yourself. So, my guess is that there is something sufficiently different about the hardware details beyond the MCU that is causing this software stack to deviate in its dialog sequence with the host and to flag an error. You may need to dig into the software stack, itself. \$\endgroup\$ Commented Sep 6 at 22:04
  • \$\begingroup\$ To get an answer more detail is required about the custom board. E.g. what device provides the USB 2.0 HS interface, and is it programmed with any firmware? \$\endgroup\$ Commented Sep 6 at 22:06
  • \$\begingroup\$ @Justme these boards were previously built by an associate of mine and at that time they worked fine. The faulty board was built according to the working schematic. The MCU is an XMOS chip with a physical layer included and we use vendor firmware for it. As for posting schematics, I am currently unaware of how to do that on this site, so it may be a little bit before I do. \$\endgroup\$
    – radon2112
    Commented Sep 8 at 19:06
  • \$\begingroup\$ @periblepsis I apologize if my post was a bit misleading at first. When I mentioned that the "USB communication worked fine," I was mainly referring to the board's ability to correctly transmit its device descriptor data to my laptop. Beyond that I'm not sure that any communication is actually happening. Your assumption is true regarding the software library, and I have reason to believe that the software stack is somewhat to blame (the board seems to get stuck in a USB_Reset state as evidenced by a register dump). I'll keep looking into that. \$\endgroup\$
    – radon2112
    Commented Sep 8 at 19:09

2 Answers 2

3
\$\begingroup\$

why is my device able to maintain USB communication with my computer as shown above?

The communication shown above is not with your device, it is between the system driver and runtime registers of your host controller. What actually happens on the bus between the host port and device is unknown.

From the wireshark trace it follows only that your device only pulls-up its D+ wire, which results in "CONNECT" status on PORTSC[3] register. As the host sees the connection, it tries to "enable" the port, which can be done only by issuing PORT_RESET command.

The reset very likely does through (nothing usually can prevent it), but the return status is not shown in your trace. You should include results of PORTSC reads to understand if your device really responds to reset, or it is a FS device, or it is simply dead. I am not sure if the wireshark is capable of this.

In any case some status will be returned, and the host will proceed with the enumeration process.

So, the host will send SET_ADDRESS command, the port will send SETUP-DATA tokens out, but apparently your device does not understand it and returns nothing. Set address fails, because your device was not able to maintain USB communication.

Now about possible scenarios why this can happen:

  1. Your board has no valid FW to activate internal USB functionality;
  2. Your board has no clock;
  3. Your board does not have proper power-on reset;
  4. The device clock frequency is way out of specifications.

Usually this situation requires capturing oscilloscope traces of D+ and D- wires, properly triggered and with sufficient sampling rate and buffer depth.

\$\endgroup\$
14
  • \$\begingroup\$ Thank you, I was unaware of Wireshark's functionality in that respect. As I mentioned in a comment above, however, I believe that the device in fact can maintain some level of USB communication, as the GET DESCRIPTOR response packet contains the correct descriptor data as programmed in the device's firmware. Surely this data cannot be acquired by the host without some level of involvement on the device's part? At any rate, I will investigate the board and determine whether or not the listed reasons you gave apply to the board. And thank you for broadening my knowledge of Wireshark! \$\endgroup\$
    – radon2112
    Commented Sep 8 at 19:17
  • \$\begingroup\$ @radon2112, "as the GET DESCRIPTOR response packet contains the correct descriptor data" - I don't see any device response in the posted wireshark log. Under Linux, the first command is SET_ADDRESS, only then GET_DESCRIPTOR. If set address fails, no get_descriptor will follow. Under Windows it is opposite. Which OS did you use when running the wireshark? \$\endgroup\$ Commented Sep 8 at 19:46
  • \$\begingroup\$ ` DEVICE DESCRIPTOR bLength: 18 bDescriptorType: 0x01 (DEVICE) bcdUSB: 0x0200 bDeviceClass: Vendor Specific (0xff) bDeviceSubClass: 255 bDeviceProtocol: 255 bMaxPacketSize0: 64 idVendor: XMOS Ltd (0x20b1) idProduct: Unknown (0x00b1) bcdDevice: 0x1000 iManufacturer: 1 iProduct: 2 iSerialNumber: 0 bNumConfigurations: 1 ` This is the data obtained in the response shown in line 24 of the posted log. The log was captured on Debian Linux. \$\endgroup\$
    – radon2112
    Commented Sep 8 at 20:19
  • \$\begingroup\$ @radon2112, why did you conceal this information? This is a completely different game. \$\endgroup\$ Commented Sep 8 at 20:42
  • \$\begingroup\$ That was my mistake. At the time, I had thought it sufficient to include line 24 in the log I posted, as I did not know what I know now about USB. I am also still figuring out how to navigate this site and ask good questions in the forum :/ I have edited the body of the original post to include the above information. \$\endgroup\$
    – radon2112
    Commented Sep 8 at 20:44
0
\$\begingroup\$

Wouldn't a hardware issue imply that no USB packets would be able to be sent?

Not exactly. Tho only data that is exchanged between host and your device is the GET DESCRIPTOR request+response. Everything else is just the hub in front of your device.

The issue here is that the GET DESCRIPTOR Response DEVICE is run at USB full speed (not high speed) but the following switching to high speed is the point that fails somehow.

This implies that your board schematic should be OK-ish, but you need an adult to look at your layout in order to find the HF problem that prevents USB high speed to run properly.

\$\endgroup\$
4
  • \$\begingroup\$ Ah, I see. I was unaware that such transactions were run at full speed. So when dmesg gives the following new high-speed USB device number 22 using xhci_hcd, chronologically speaking this message occurs after the device descriptor is received? \$\endgroup\$
    – radon2112
    Commented Sep 8 at 19:24
  • \$\begingroup\$ Turbo J, how did you determine that the listed transactions went at FS? \$\endgroup\$ Commented Sep 8 at 19:53
  • \$\begingroup\$ USB Spec itself dictates that. \$\endgroup\$
    – Turbo J
    Commented Sep 9 at 8:01
  • \$\begingroup\$ USB Spec does not dictate that. All depends on FS-HS handshake during USB_RESET. The log has no indication that the transaction went at FS. The port status indicates that the port is in HS mode before running GET_DECRIPTOR \$\endgroup\$ Commented Sep 11 at 0:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.