• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 6977 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

L138: USB Failed GetDescriptor(iProduct) and GetDescriptor(iSerialNumber) request

Kiung Chung Wong
Expert 2110 points

Hi,

I am using Zoom OMAP L138 eXperimenter Kit and DaVinci-PSP-SDK-03.20.00.14.

I have configured the Linux kernel as USB device (gadget). I have tried USB Ethernet/RNDIS Gadget (g_ether.ko), USB Serial Gadget (g_serial.ko), and File Storage Gadget (g_file_storage.ko).

I have captured the USB bus traffic during enuemeration for these gadgets. All of them failed GetDescriptor(String iProduct) request.

Original g_ether.ko and g_serial.ko do not support GetDescriptor(String iSerialNumber) request, I have modified the below respective file so these 2 gadgets also support GetDescriptor(String iSerialNumber) request.

drivers/usb/gadget/ether.c

drivers/usb/gadget/serial.c

Both Ethernet and Serial Gadget also failed GetDescriptor(String iSerialNumber) request. The File Storage Gadget actually passed this request after host retries for 12 times.

Below I attached the enumeration capture from Ellysis for each of this gadget. Not sure anyone in the community facing the same problem. If yes, how it is solved.

I am working on USBTMC device. The iSerialNumber is crucial for USBTMC application. And the problem is only happened in high-speed, full-speed is working fine.

Hopefully TI can help or provide some advice. Appreciate that.

 

 

 

 

rgds,

kc Wong

  • 0
    Expert 2110 points

    Hi,

    Not sure if TI has any comment on this ?

    From all the 3 gadgets tested, it seems that host has to always retry the GetDescriptor(String iProduct) and GetDescriptor(String iSerialNumber) requests. Why ???

    From the below MSDN blogs, I believe the first 3 GetDescriptor(String iSerialNumber) requests are from Windows USB bus driver. I expect these request to pass at this stage.

    http://blogs.msdn.com/b/usbcoreblog/archive/2009/10/31/how-does-usb-stack-enumerate-a-device.aspx

    By the way, what is the next level of support that I can get from TI to further investigate this issue in the case that I don't get any further help from TI E2E Community ?

    rgds,

    kc Wong

  • 0 in reply to Kiung Chung Wong
    Expert 2110 points

    Hi,

    I have thought that by sending more GetDescriptor(String iSerialNumber) requests, it will have better chance to get the iSerialNumber.

    We are not able to modify the Windows USB bus driver, but we have modified the client class driver to send more GetDescriptor(String iSerialNumber) requests right before SetConfiguration request. Unfortunately, all of the requests failed.

     Then, I tried again with the device in full speed mode. As you can see, all the GetDescriptor(String iSerialNumber) requests are successful. There are 20 of them. In fact, it succesfully get the string for iManufacturer and iProduct as well.

    Hopefully TI can comment on this. What is the next step that I can take to solve this issue ???

    rgds,

    kc Wong

  • 0 in reply to Kiung Chung Wong
    Expert 2110 points

    I downloaded libusb-win32. This library allows user space applications to access many USB device on Windows in a generic way without writing any line of kernel driver code.

    http://libusb.sourceforge.net/api-1.0/

     

    With this library, I built application to just send GetDescriptor(String iSerialNumber) requests to the device. As expected, they all failed.

     

    As I experimented further with different wLength for this request, I will get different result. For example, if wLength =256, I have better chances to have the request successful.

     

    Setup packet with wLength = 255, always failed the request.

    80 06 03 03 09 04 FF 00

    Setup packet with wLength = 256, always successful with the request.

     80 06 03 03 09 04 00 01

     

    This is the hypothesis I think. The binary of 255 is eight 1s. The continuous of eight 1s in the bit stream is causing this issue in high speed when the hardware  is marginally passed the signal integrity. I suspect the LogicPD board design, as there is a long trace length from USB connector to the USB controller (OMAP L138) on the SOM board and even with the connector in between.

     

    As I looked back at the capture for Linux-USB File Storage Gadget (Mass Storage Device), the wLength is 26 for this request.

    Anyway, we have modified our class client driver to send additional GetDescriptor(String iSerialNumber) requests to the device and of couse with other value of wLength. These requests are succesful, but doesn't help becasue the Windows builds the Device Instance ID based on the requests it makes, doesn’t matter whether other driver layer has this request successful or not (based on observation).

    Unless we have a way to modify Windows USB bus driver with different value of wLength for this request, or else this request will always fail using OMAP L138 eXperimenter Kit.

     

     rgds,

    kc Wong

     

  • 0 in reply to Kiung Chung Wong
    Expert 2110 points

    Hi Zegeye Alemu,

    I see you made a lot of useful comments on the other posts, not sure you have any comment on this ???

    rgds,

    kc Wong