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

OMAP3503 CE6.0 EHCI Suspend/Resume

Sarah Read
Prodigy 10 points
Other Parts Discussed in Thread: OMAP3503, TUSB1210Intermittently, USB devices (ie. usb memory stick and USB modem) do not recover from suspend/resume cycles on our platform. When the platform is in this state, physically detaching and reattaching a device has no effect.

The hardware configuration is OMAP3503 HSUSB2 connected to a TUSB1210 (ULPI interface). The downstream port of the TUSB1210 is connected to an SMSC USB2513 hub. The software is WinCE BSP version 6.15.00.

Here are some things I have tried:
1. Bypassed the hub to isolate the problem to the OMAP and PHY.
2. Queried the ULPI registers for the Vendor and Product ID successfully when in the failure state, so the PHY is still active.
3. Implemented Workarounds 1&2 for Advisory 3.1.1.157 in the OMAP 35x Errata. This had no effect.
4. Used a USB analyzer to capture the USB traffic between the device and the PHY. In both the successful and failed suspend/resume cases, the analyzer captures the following sequence with no significant timing differences:

Suspended
Reset
High Speed Detection Handshake TIMEOUT

5. Suspend/resume again while in the failed state causes device enumeration to fail on the GetDescriptor stage (see traces below) for any subsquent attempts, until the platform is power cycled.

3831178 PID:400002 TID:957000a CHub(Root tier 0)::HubStatusChangeThread - device attached on port 2
3831178 PID:400002 TID:957000a +CHub(Root tier 0)::AttachDevice - port = 2, fIsLowSpeed = 0, fIsHighSpeed =1
3831178 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_OPENING_ENDPOINT0_PIPE, failures = 0
3831178 PID:400002 TID:957000a +CControlPipe::OpenPipe
3831178 PID:400002 TID:957000a +CPipe::AddToBusyPipeList - new pipe(Control) 0xd4349a20, pri 0
3831179 PID:400002 TID:957000a -CPipe::AddToBusyPipeList - new pipe(Control) 0xd4349a20, pri 0, returning BOOL 1
3831179 PID:400002 TID:957000a -CControlPipe::OpenPipe
3831179 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_USING_ADDRESS0, failures = 0
3831179 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_RESET_AND_ENABLE_PORT, failures = 0
3831252 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST, failures = 0
3832271 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - failure on DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST step
3832272 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_RESET_AND_ENABLE_PORT, failures = 1
3832345 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST, failures = 1
3833364 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - failure on DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST step
3833365 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_RESET_AND_ENABLE_PORT, failures = 2
3833438 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST, failures = 2
3834457 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - failure on DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST step
3834458 PID:400002 TID:957000a CHub(Root tier 0)::AttachDevice - status = DEVICE_CONFIG_STATUS_FAILED, failures = 3
3834458 PID:400002 TID:957000a +CBulkPipe(Control)::ClosePipe
3834469 PID:400002 TID:957000a +CBulkPipe(Control)::ClosePipe

Any suggestions on what I could try next would be appreciated.
Thanks,
Sarah
  • 0
    TI__Expert 3710 points

    You are on a very old release. If possible I would recommend using the latest BSP from here

    http://focus.ti.com/docs/toolsw/folders/print/wincesdk-a8.html

    There has been several fixes in this area. If you can wait a week or so, we are planning to make another release with more fixes. 

    thanks

    Atul

  • 0 in reply to Atul Verma
    Prodigy 100 points

    Atul,

    I am working with Sarah on this issue.  I have brought forward the changes in V1.1.0, but it has not addressed the EHCI suspend / resume issue.  I have made modifications to the SuspendHostController and ResumeHostController to follow the EHCI spec and properly disable and enable the periodic and asynchronous schedules.   It appears to be working now, pending further testing.

    When is the next version of the BSP coming out?  I would like to validate my changes versus that.

    Thanks,

    Cam

  • 0 in reply to Cam Turner
    TI__Expert 3710 points

    The release is ready - we are just going thru internal processes to make it available on the Web. Pl. look for an announcement over next couple of days. Appreciate your patience

     

    Atul

  • 0 in reply to Atul Verma
    Prodigy 100 points

    Atul,

    There were no changes to the USB ECHI driver between 1.1.0 patch 1 and 1.2.0.

    Just to close the loop on this thread, as I mentioned I modified CHW::SuspendHostController and CHW::ResumeHostController.  On suspend, I needed to disable the asynchronous and periodic schedules, then suspend each port and finally stop the controller.  For resume, just reverse the order.

    Cam