• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 100 subscribers
  • Views 1189 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

USB Enumeration Problem on EZDsp5535 kit

Bruno Paillard
Intellectual 945 points

Dear TI staff

I am working on the USB aspects of the EZDsp5535.

I based the USB firmware layer on CSL_USB.

I notice that when enumerating in High-Speed, sometimes (once every 10 or 20 connections) the first GetDeviceDescriptor request from the host (just after the SetAddress request) is not acked. The host transmits 3 GetDeviceDescriptor requests in a row. None are acked. Then the host resets the bus, and starts enumerating again. Most of the time the second attempt, after the USB reset, succeeds.

At first I suspected my code. However, it appears that the Connected-Audio-Framework software does the same thing. To demonstrate, simply rebuild the Connected-Audio-Framework demo, simply comment-out the call to USB_setFullSpeedMode() in csl_usb_iso_fullspeed_example.c, so the demo will enumerate in high-speed.

I know that it is not proper to have an audio-class 1.0 device enumerate in high-speed, but that is irrelevant here because:

- A Windows host will enumerate a high-speed Audio-Class 1.0 device normally (as if it was full-speed)

- The problem occurs at the first GetDeviceDescritor request, just after the initial SetAddress request. At that time the host does not yet know that the device is audio-1.0. All it knows is that it just addressed a new device on the bus, and is trying to read its device descriptor.

Thank you for your help

Regards

Bruno

  • 0
    TI__Mastermind 23785 points

    Hello Bruno,

    Let me try to answer your question.

    When a device is attached to a hub, the hub will inform the host and perform reset to the new device (I think this is what you see). The spec requires the host waits at least 100ms for the new device and hub to complete their process. The host will then read the device descriptor to determine how to interface to the device. This is where the speed mode is determine.

    Does this explains what you see?

    Regards.

  • 0 in reply to Steve Tsang
    Intellectual 945 points

    Hi Steve

    Not quite.

    On a Windows high-speed-capable host the enumeration proceeds as follows: (probably on other hosts as well, although the exact sequence may vary a bit from host driver to host driver).

    1) The host detects the newly connected device (in full speed)

    2) The host then attempts to negotiate high-speed with the device (sends the high-speed chirp and waits for the response). If the device is high-speed capable the host and device switch to high-speed signaling.

    3) The host then sends an initial GetDeviceDescriptor request. The device is not addressed yet, but it must respond to that request at address 0.

    4) After parsing that descriptor  the host then resets the bus and renegotiates the high-speed transition

    5) The host addresses the device (sends a SetAddress request). At that time the device has its address, and will stop responding to address 0, and respond to the newly-defined address.

    6) After addressing the device the host sends a new GetDeviceDescriptor request, but this time at the newly-defined device address. This is the first step in discovering the complete set of device descriptors.

    The problem that I see occurs at step 6. The host has sent the SetAddress request, which the host has acked. At that time the device is supposed to respond at the new address. Then the host sends the GetDeviceDescriptor request, which the device DOES NOT ACK.

    The host then proceeds to send 2 more GetDeviceDescriptor requests very close together (within 5 us of each other). The device does not ack either of them. Then the host resets the bus and does everything again from the top. The second time around the device usually responds correctly.

    Everything looks like the device has not programmed its address register properly after the SetAddress request.

  • 0 in reply to Bruno Paillard
    TI__Expert 3260 points

    Hello Steve,

    Do you have an update on this?

  • 0 in reply to Michael W
    TI__Mastermind 23785 points

    I am working on capturing an USB transaction with an USB bus protocol analyzer.

    Regards.

  • 0 in reply to Steve Tsang
    Intellectual 945 points

    Hi Steve

    Let me know if you need me to capture one. I should not be too difficult to set up the test again.

    Bruno

  • 0 in reply to Bruno Paillard
    TI__Mastermind 23785 points

    Hi Bruno,

    Yes. Please.

    Regards.

  • 0 in reply to Steve Tsang
    Intellectual 945 points

    Hi Steve

    I made a file for TotalPhase's Beagle 5000. If you do not have that analyzer, the software is downloadable for free from the www.totalphase.com web site.

    The file is almost 3 MB. It is zipped. You can download it from

    http://dl.dropbox.com/u/24636754/C5535EZDsp_EnumProblem.zip

    The problem is visible at index location 5059

    Let me know how it goes.

    Regards

    Bruno

  • 0 in reply to Bruno Paillard
    TI__Mastermind 23785 points

    Thanks. I will check it out.

    Regards.

  • 0 in reply to Steve Tsang
    TI__Mastermind 23785 points

    Hello Bruno,

    We know the csl example works. You cannot just comment out the call. Instead, change it to USB_setHighSpeedMode() and try again.

    Regards..

  • 0 in reply to Steve Tsang
    Intellectual 945 points

    Hi Steve

    1) There is no mention of USB_SetHighSpeedMode() function (or any similar function) in the USB CSL library documentation. I am using the html documentation that is supposedly the most up-to-date document.

    2) If I try to use that name in the code the project does not link with an error indicating that the above function is not resolved.

    I must conclude that the function you are referring to does not exist...!

    Should I be talking to someone else...?

  • 0 in reply to Bruno Paillard
    TI__Mastermind 23785 points

    Hi Bruno,

    We took this capture with USB example 3 in CSL 2.50 release at High Speed. I attached the host driver for this to work.

    .1731.C5505_USB_Host_Tool.zip

    In order to get the Connected-Audio-Framework demo to work in high speed requires additional modifications. It is entered as an enhancement request for future CSL release.

    Thanks.

  • 0 in reply to Steve Tsang
    Intellectual 945 points

    Hi Steve

    I am not interested in the audio-class implementation, but I had hoped to reuse the USB framework in another design. From your answer I guess this is not a good idea...

    Do you have any information about the "additional modifications" required to make that framework respond reliably to the SetAddress request in high-speed?

    I notice that the example that you demonstrate does all the USB processing in the interrupt. Could it be a question of response time?

    Thank you for your help

    Bruno

  • 0 in reply to Bruno Paillard
    Intellectual 945 points

    Hi Steve

    I finally found the problem in project "CSL_USB_IsoFullSpeedExample_ezdsp_Out". It is located at lines 556 and 557 of app_usb.c

    In those lines the PERI_CSR0_INDX register is updated in two separate steps:

    1)   usbRegisters->PERI_CSR0_INDX |= CSL_USB_PERI_CSR0_INDX_SERV_RXPKTRDY_MASK;
    2)   usbRegisters->PERI_CSR0_INDX |= CSL_USB_PERI_CSR0_INDX_DATAEND_MASK;

    Between step 1 and step 2 there is a window of opportunity for the host to send the next IN packet, BEFORE the DATAEND bit has been set, thereby triggering a SetupEnd error condition.

    This happens during the handling of a number of other requests (for instance lines 431-432, 443-444...etc.). But in those other cases the error is more benign because the processing is done immediately and the error is cancelled at the next setup packet (at the next request). This is fatal for Set-Address however because the processing of this request is performed in the CSL_USB_EP0_STATUS_IN stage of the request... And does not get processed when the error occurs.

    In order to correct the problem, both flags should be set at once, as in:

    usbRegisters->PERI_CSR0_INDX |= (CSL_USB_PERI_CSR0_INDX_SERV_RXPKTRDY_MASK | CSL_USB_PERI_CSR0_INDX_DATAEND_MASK);

    By the way, the problem ALSO OCCURS IN FULL-SPEED in that example project, not just in high-speed as I said earlier.

    The USB Command Verifier is a very good way to demonstrate the problem because of the 150 consecutive enumerations... The probability of the error is high-enough that the device never goes through all the 150 enumerations.

    Also, you may want to check the handling of other requests, because that example DOES NOT PASS several of the other tests of the USB Command Verifier.

    Hope this helps. Don't hesitate if you have any question.

    Regards

    Bruno

  • 0 in reply to Bruno Paillard
    TI__Mastermind 23785 points

    Bruno,

    Thanks. I have logged it for CSL development.

    Regards.