• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 555 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.

AM3354: USB0 enumeration error

Brian Angiel
Expert 4220 points
Part Number: AM3354


Hi team,

 

I am experiencing a problem with the USB0 port of one of my AM3354-based systems.

 

I am having trouble enumerating a cap touch controller board based on an Atmel cap touch controller IC. The controller board is from an outside vendor. Upon power up, the controller board does not enumerate, and the port shuts down, dropping Vbus. I receive a Babble interrupt when this happens. The problem doesn't always happen at the same point in the enumeration process. Sometimes no packets are exchanged, sometimes I see SOF packets, and sometimes I get all the way through to the first data exchange with SETUP packets transmitted and ACKd by the cap touch controller. Then the port shuts down.

 

Now, in the USB 2.0 specification, there is a time interval called out as Tsigatt, which is the maximum time from when Vbus is up to valid level to when a device has to signal attach. My cap touch board is a full speed device so it signals attach by driving D+ to the high state.

 

I have two cap touch boards that are used with this system. One is for an 8 in. LCD display and one is for a 10 in. 

  • The 8 in. controller always seems to enumerate successfully--it takes about 80 ms to drive D+ high following Vbus startup.
  • The 10 in. controller takes from 100 ms to 103 ms.  It rarely enumerates correctly--maybe 1 or 2 of ten tries.  When it does enumerate successfully, it appears to continue to maintain valid communication.
  • If I interpose an older USB 1.0 hub between the AM3354 port and my cap touch board, I see the hub driving D+ high very quickly after Vbus rises--within a ms. And the 10 inch cap touch board always works with this hub.
  • When I view the D+ and D- signals, I don't see any signal integrity issues--noise is minimal and rise and fall times appear to be fine. I can decode the USB packets with their Tek scope, and they appear to be valid.
  • I can plug a USB drive into the port and watch it setup a high speed connection--it always works fine.

 

Could this 100 ms timeout be the source of the problem? How is that time interval set within the AM3354 USB subsystem--is it register programmed, or set by the driver?

 

Going back to the spec, it says the Tsigatt time interval to be <100 ms for "all hub and device implementations".  This is what I am concerned about.  The spec is called out on Page 150 and shown in Figure 7-29 of the USB 2.0 Serial Bus Specification Revision 2.0.


Thanks,

Brian

  • 0
    TI__Guru**** 173081 points

    Hi Brian,

    The USB Spec does have this timing requirement, but I am not sure this is really the cause of the enumeration issue.
    Do you use Linux? What is the Processor SDK Linux version?
    Is the USB0 port is configured as "host" mode or "otg" mode in device tree? Please check its dr_mode setting in dt.

  • 0 in reply to Bin Liu
    TI__Expert 4220 points
    Hi Bin,

    I am using Linux; the kernal version is 3.12.
    The USB0 port is configured as "host" (dr_mode).

    Brian
  • 0 in reply to Brian Angiel
    TI__Guru**** 173081 points
    Brain,

    Can you please confirm that you *always* see the Babble interrupt when the issue happens?
    Kernel v3.12 is very old and no longer supported. I am not sure if that kernel has implemented a babble recovery mechanism. Can you please test with a newer kernel to see if the usb device can be enumerated after the babble event happens?
  • 0 in reply to Bin Liu
    TI__Expert 4220 points

    Yes, I always get the Babble interrupt when this happens. I am not yet in a position to test with a newer kernel.

    What I am trying to understand, though, is why the Babble interrupt occurs in the first place. I don't see any evidence of noise or failed communication during the enumeration process--the only difference I see is that the Captouch board that drives D+ high in 80 ms ALWAYS enumerates successfully and the Captouch board that drives D+ high in 102 ms enumerates maybe 1 out of 10 times. USB drives work every time. Interposing a hub in between the AM3354 port and the Captouch board fixes the problem (the hub drives D+ high within a few milliseconds of Vbus startup).

    Any insight you can provide to help me understand the root cause of this would be greatly appreciate. Thanks!

    Brian

  • 0 in reply to Brian Angiel
    TI__Guru**** 173081 points

    Brian,

    Babble doesn't have to be caused by a *real* line noise. From the USB controller's perspective, it only means D+/D- detects an *illegal* bus activity which supposed to be in idle state at that time.

    But I don't have an explanation why the device pulling up D+ in 102ms will trigger a babble event, but I don't believe the USB controller has an internal timer counting for this 100ms timeout defined in the USB Spec. I have a usb device which enables D+ pullup in about 1 sec and can still be enumerated properly with AM335x USB.

    We have seen a few systems with AM335x which had such babble issue, one way to workaround the problem is to use the kernel babble recovery mechanism, which is that the usb driver detects the babble event and re-start the VBUS power, in most cases it will be able to enumerate the device.