• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 363 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.

issues EHCI functionality on OMAP35xx

burchmere
Intellectual 930 points

I'm having issues getting USB up and going on HSUSB2/EHCI on an OMAP35xx.  We're using an SMSC3317 connected to HSUSB2, and in turn, the 3317 is connected to an onboard hub - a USB2513.  When the hub is removed from reset, it appears that handshaking/chirping starts to happen between xcvr and hub, but ends with the code announcing that it is "unable to enumerate" the device.  This appears to be the case because we never see PED set in the PORTSC_1 reg (and we are seeing PO=1 which doesn't make any sense).

Kind of new to this low level USB functionality, so a few questions...
1.  Any ideas why we'd see PORTSC_1[PO] = 1?

2.  Any suggestions on debugging basic connectivity between 35xx EHCI controller and transceiver + hub?

In the meantime, I'll be scouring the forum for more info.

Thanks,

twebb

  • 0
    Intellectual 930 points

    By the way, we're running a git-based 2.6.27-omap1 kernel.  Is anyone aware of 2.6.27 issues with EHCI, or any patches that might be required to get EHCI goinng?

    Compared to beagle board that we're using as a reference (virtually same xcvr and then we connect to standalone hub to emulate our real hardware) our code looks identical - but beagle board works fine (with some patches) and ours doesn't.  Beagle code is based on 2.6.28 I believe.

     

  • 0 in reply to burchmere
    TI__Genius 9460 points

    Here is the PED (Port Enable/Disable) description:

    Ports can only be enabled by the host controller as a part of the reset and enable.

    Software cannot enable a port by writing a one to this field. "The host controller

    will only set this bit to a one when the reset sequence determines that the

    attached device is a high-speed device"

     

    So it seems there is some problem in detecting high speed signaling.

     

    PO (Port Ownership) description:

    System software uses this field to release ownership of the port to a selected

    Host controller (in the event that the attached device is not a high-speed device).

    Software writes a one to this bit when the attached device is not a high-speed

    device. "A one in this bit means that a companion host controller owns and

    controls the port."

     

    This is in same line as above. As there is problem in detecting high speed

    Signaling so the ownership is given to other host controller for the attached hub.

     

    If you have any method to verify the high speed signaling from the EHCI phy then please

    check if everything is as per specs.

     

    Ajay

  • 0 in reply to Ajay
    Intellectual 930 points

    I believe the problem has been narrowed down to access problems between ehci controller and transceiver on the 12-pin ULPI interface when accessed via INSNREG05_ULPI.  Even readback of RO registers (like Vendor ID High) doesn't work consistently.

    Very puzzling.  Any ideas anyone?

  • 0 in reply to burchmere
    Prodigy 75 points

    Even i am facing the same issue, Anyone has found out the problem, as to why not able to read the Vendor ID, I am using the Port 2