none
Winusb c++ superspeed protocol issue RRS feed

  • Question

  • Hi,

    I am trying to build a USB 3.0 Device. I am having some trouble getting the usb enumeration to work correctly for super speed. My enumeration works correctly on a OSX, so I know descriptors are correct. But on windows the BOS descriptor is not picking up the superspeed capability part (Verified this using message analyzer).

    The device works but under high speed devices. Do I need to have special BOS descriptor for windows? I have added the Microsoft OS descriptor 1.0 and the device is listed under the winusb devices in device manager.

    Also I am seeing most of the superspeed devices listed as highspeed devices on multiple different laptops. Is there a issue with superspeed devices for windows? I think there is a bug with BOS descriptor parsing in windows and this is causing device to enumerate as high speed instead of superspeed.

    I think that when decoding the USB 3.0 Binary Object descriptor (BOS) the Microsoft message analyzer has a couple of issues.

    My device uses a Cypress FX3 and has a BOS descriptor as follows:

    /* Binary device object store descriptor */
    const uint8_t CyFxUSBBOSDscr[] __attribute__ ((aligned (32))) =
    {
        0x05,                           /* Descriptor size */
        CY_U3P_BOS_DESCR,               /* Device descriptor type                (0x0F) */
        0x16,0x00,                      /* Length of this descriptor and all sub descriptors */
        0x02,                           /* Number of device capability descriptors */
    
        /* USB 2.0 extension */
        0x07,                           /* Descriptor size */
        CY_U3P_DEVICE_CAPB_DESCR,       /* Device capability type descriptor     (0x10) */
        CY_U3P_USB2_EXTN_CAPB_TYPE,     /* USB 2.0 extension capability type     (0x02) */
        0x02,0x00,0x00,0x00,            /* Supported device level features: LPM support  */
    
        /* SuperSpeed device capability */
        0x0A,                           /* Descriptor size */
        CY_U3P_DEVICE_CAPB_DESCR,       /* Device capability type descriptor     (0x10) */
        CY_U3P_SS_USB_CAPB_TYPE,        /* SuperSpeed device capability type     (0x03) */
        0x00,                           /* Supported device level features  */
        0x0E,0x00,                      /* Speeds supported by the device : SS, HS and FS */
        0x03,                           /* Functionality support */
        0x0A,                           /* U1 Device Exit latency */
        0xFF,0x07                       /* U2 Device Exit latency */
    };

    The app reads it during the session and when I look at the data all 22 bytes are present in the message data window. However, the descriptor is only decoded to the end of the first device capability (the USB 2,0 extension), and it incorrectly decodes the 4 'supported device level features' bytes so that instead of showing that the LPM bit is set (1) and that Reserved1 and Reserved2 are are reset (0) it shows that Reserved2 is set to 32768 (0x8000) and LPM and Reserved 1 are reset (0).

    Is anyone else seeing this problem?






    • Edited by Yunus Dawji Wednesday, December 6, 2017 11:35 AM
    Monday, December 4, 2017 1:13 AM

All replies

  • Can you capture traces using the following instructions and share?

    https://blogs.msdn.microsoft.com/usbcoreblog/2014/09/02/capturing-usb-debug-traces 


    Makarand Sonare

    Tuesday, December 5, 2017 7:57 PM
  • Thanks a lot! The Usb BOS descriptor looks ok. But then I checked the device speed using winusb c++ example.

    https://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx

    And I see that in winusbio.h there is only low, full and highspeed define. (No superspeed)

    Is superspeed supported by winusb c++?


    Also the protocol is little different in superspeed and highspeed usb transfers . Since the winusb is returning device speed as highspeed and my fx3 is in superspeed,i think my transfers are getting stuck because of this. Does winusb c++ api support superspeed transfers?
    • Edited by Yunus Dawji Wednesday, December 6, 2017 1:33 AM
    Wednesday, December 6, 2017 12:37 AM
  • Also I am seeing most of the superspeed devices listed as highspeed devices on multiple different laptops. Is there a issue with superspeed devices for windows?

    If you will forgive the obvious question, are you sure the laptops you're testing have SuperSpeed ports, and that you are plugging into one?  The USB jack must have the blue interior, otherwise it is a USB 2 port.  There is certainly no generic problem with SuperSpeed, at least since Windows 8 where the support was added.

    The app reads it during the session and when I look at the data all 22 bytes are present in the message data window. However, the descriptor is only decoded to the end of the first device capability...

    What app?  If you're using USBView, it's quite possible that you have an old version that doesn't understand USB 3.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    • Proposed as answer by makason Friday, December 8, 2017 6:18 PM
    Wednesday, December 6, 2017 10:29 PM
  • WinUSB doesn't care.  As long as you're not using bulk streams, the URB format is identical to USB 2.

    In Device Manager, in "Devices by Connection," is your device actually listed under an xHCI controller?  If it is listed under an EHCI controller, then it is enumerating as high-speed, and you can't make super-speed requests of it.

    Tim


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    • Proposed as answer by makason Friday, December 8, 2017 6:18 PM
    Wednesday, December 6, 2017 10:33 PM
  • The protocol for superspeed bulk transfer is a bit different that highspeed bulk transfer. Only for the part when you miss a read/write (this means that when there is no data to read or host is not ready to accept a write request).

    Its explained well here

    https://msdn.microsoft.com/en-us/library/windows/hardware/ff539199(v=vs.85).aspx

    I think windows is perform highspeed protocol even on a superspeed device. And this is causing the data transfer to stall. I don't have a usb 3.0 analyzer so I cannot confirm it but I am 99% sure.

    Sunday, December 10, 2017 6:38 PM