• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 103 subscribers
  • Views 11924 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.

AM3352: USB_DRVVBUS does not stay active when device connected

Wilfried Kramer
Prodigy 150 points
Other Parts Discussed in Thread: TMDSSK3358, AM3352, SN74CBT1G384

Hello all,

I have a problem with USB port operation on AM3352 processor. The system is a custom board, in part based on Starter Kit design TMDSSK3358.
The port USB1 operates as OTG, and USB 5V power is generated by Micrel MIC2026-1YM circuit. It is stabilized by 100uF and 0.1uF.

When I plug an adapter cable (for e.g. USB stick, ID connects to GND) to the port, USB1_DRVVBUS raises from low to high state. The MIC2026 requires about 2ms to provide the full voltage of +5V. This USB-Power supply directly connects back to USB1_VBUS on AM3352.

Problem is, the power stays active for about 100ms, and then drops. This cycle repeats 4 times, and then the power stays off. The software reports about "VBUS raise wait,  fail".

Why does this happen? I know the VBUS signal is probed by AM3352 for voltage high enough. Any voltage too low causes this pulsing. But in this case the level is definitely +5V, not less than 4.9V. This should not be a reason for that failure.

Any help is really appreciated.

Best Regards
Wilfried Kramer

  • 0
    TI__Mastermind 27720 points

    Hello Wilfried,

    The 100ms timeout you see is a function of the USB controller hardware itself...in Host mode, the controller will assert DRVVBUS and then wait 100ms for >=4.4V to appear on USBn_VBUS. If the voltage is not present on this pin before the timeout, the controller assumes that the VBUS power supply is either not present or is in OC protection mode and will de-assert DRVVBUS to prevent damage to the system.

    Have you measured the USB1_VBUS pin to ensure that the voltage is >=4.4V?

  • 0 in reply to -DK-
    Prodigy 150 points

    Hi -DK-,


    first thanks for the technical details. I did not know it is 100% controlled by the USB controller hardware.

    But I am aware of the principle of operation with VBUS signal. Yes, I measured the USB1_VBUS signal, at least direct at the connector. It is +5V, guaranteed not less than 4.9V. So the 4.4V criterion is fulfilled.

    The pin 1 on the OTG connector straight connects to USB1_VBUS signal. OK, the processor is on a module, I'll verify the voltage on the module to be sure. But normally this can not cause a drop of 0.6V.

    In the TMDSSK schematics there is a 1.2K resistor at the processor. Is that important?

  • 0 in reply to Wilfried Kramer
    TI__Mastermind 27720 points

    Let us know what you find when measuring USB1_VBUS as close as possible to the pin.

    The 1.2K resistor is there to limit current. It's not 'required' per-se, but it's not a bad idea to have it. What's more important is that it not exceed 1.2K.

  • 0 in reply to -DK-
    Prodigy 150 points

    On my oscilloscope I see a mean voltage of 4.94 volt, naturally with a little noise. Lowest level is 4.88V, highest is at 5.0V. Any further idea?

    I compared signals an levels with the Starter Kit. Only difference I see is the raise time for VBUS, 1.6ms on TMDSSK and 2.0ms on my design. That can't be the reason either.

  • 0 in reply to Wilfried Kramer
    Intellectual 300 points
    Your design have capacity load or check the power assumption at your design. Try to use the power supply at your USB slave device.
  • 0 in reply to Gaven Liu
    Prodigy 150 points

    Yes, there are capacitors to stabilize the USB +5V rail, as necessary.
    The small difference in rise time is due to circuits from different manufactures:
    TMDSSK: TPS2051BD, my Design: MIC2026-1YM.
    Since the voltage is probed 100ms after DRVVBUS active this should be OK.

    Here is the output of the driver for USB1 when initializing (Linux):

    [    3.848814] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #1, port1 00000100
[    4.001244] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #2, port1 00000100
[    4.153651] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #3, port1 00000100
[    4.306109] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_vrise (90, <VBusValid), retry #3, port1 00080108

    For comparison, on port USB0 I have another problem, the level on USB0_VBUS is only 3.7V

    [    3.683325] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_vrise (81, <SessEnd), retry #1, port1 00000104
[    3.832326] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_vrise (81, <SessEnd), retry #2, port1 00000104
[    3.987042] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_vrise (81, <SessEnd), retry #3, port1 00000104
[    4.139762] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_vrise (80, <SessEnd), retry #3, port1 0008010c

    Does that throw some light on my problem?

    Thanks for help
    Wilfried

    By the way: does anyone know why SN74CBT1G384 only has 3.68V on pin 1 (A=output) when pin 2 (B=input) is 5V? There is only a 4.7K resistor as a pull-down on pin 1.

  • 0 in reply to Wilfried Kramer
    Prodigy 150 points

    OK, the reason for non-function is detected.


    There was some leakage from a 5V circuit. This leakage caused VDDA3P3V_USB1 supply to become 4.1V, not 3.3V as required. That's 0.8V higher than specified. Obviously this high voltage caused the failed detection of 5V on USB1_VBUS.

    Once the leakage was solved, the USB port operates fine.

    Just wanted to let you know
    Wilfried

  • 0 in reply to Wilfried Kramer
    TI__Mastermind 27720 points

    Wilfried,

    Thanks for updating this thread with root cause. I can honestly say I had never seen this particular failure before, but I'll store it away for the next time it happens. :)

  • 0 in reply to -DK-
    Expert 2190 points

    Hi Wilfried

    Excuse me, could you tell me you solve the leakage problem with SW or HW? Thank you.

  • 0 in reply to Bernie Chen
    Prodigy 150 points
    Hello Bernie,

    this was a HW modification. The connected circuits now operate on 3.3V.

    Good luck.
    Wilfried
  • 0 in reply to Wilfried Kramer
    Prodigy 40 points
    Dear Wilfried
    I have same problem . I use usb 4G-LTE module please see kernel log :
    [ 568.318175] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (89, <AValid), retry #1, port1 00000104
    [ 569.366745] usb 2-1: new high-speed USB device number 2 using musb-hdrc
    [ 577.946715] usb 2-1: new high-speed USB device number 3 using musb-hdrc
    [ 586.506744] usb 2-1: new high-speed USB device number 4 using musb-hdrc
    [ 595.066714] usb 2-1: new high-speed USB device number 5 using musb-hdrc
    [ 603.626711] usb 2-1: new high-speed USB device number 6 using musb-hdrc
    [ 612.656715] usb 2-1: new high-speed USB device number 7 using musb-hdrc
    [ 620.886842] usb 2-1: new high-speed USB device number 8 using musb-hdrc
    [ 629.306755] usb 2-1: new high-speed USB device number 9 using musb-hdrc

    LTE module work well in another PC and it need kernel driver "cdc_ether". I recompile kernel and check all dependency .But module can't work .
    Please help .
    Thanks
    Amir