• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 1426 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: VBUS issues in production

Eddie Koh
Genius 10645 points

Part Number: AM3354

Background: Customer had been mass producing with AM3354 for ~ 1 year without issues.

During recent build, 14% of the units showed a USB1 VBUS failure to supply 5V. Swap tests performed and issue followed AM3354, not PCB or PMIC.

To help customer narrow down to the root cause, here are 2 main questions:

(i) what are the possible causes of USB1_DRVVBUS toggling at startup? 

(ii) what could cause the VBUS to clamp at 3.3V when the supply +5V looks stable?

 

Image below shows the captures on 5V supply, USB1_VBUS & USB1_DRVVBUS.

 


  • 0
    TI__Guru**** 393215 points
    The USB experts have been notified. They will respond here. We will need to see the USB part of schematic too.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 393215 points
    Also, what software is used by the customer?
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 10645 points

    I have the schematcis, but not to be shared publicly. Please let me know which person to email it to.

  • 0 in reply to Biser Gatchev-XID
    TI__Genius 10645 points
    Software is Windows Embedded.

    It is the same software used in production since last year. No changes.
  • 0 in reply to Eddie Koh
    TI__Guru**** 393215 points
    You can see who this has been assigned to in the Thread Tracking Toolkit window on top of the thread.
  • 0
    TI__Mastermind 27890 points
    DRVVBUS is typically under the control of the USB driver rather than the USB controller. There are exceptions to this in which the USB controller itself will de-assert DRVVBUS:


    Controller will ignore DRVVBUS assert if VBUS is already >4.01V.
    Controller will de-assert DRVVBUS if VBUS doesn't reach >4.01V within ~100ms of assertion.

    After looking at your schematic, I see the following issues:
    USB_ID should NEVER be connected to a V-source. I know this is DNI now, but it really needs highlighting as the part can (will likely be) damaged.
    USB_ID should be tied directly to GND for Host operation. Replace the 4.7K R with 0 Ohm if Host operation is desired. Float the pin if Device/Dual-Role mode is desired.
    The USB data signals are traversing a backplane connector. This is not recommended as it will result in poor USB signal quality.
    Test points on the USB signal pairs are not permitted.
    USB0 has a Device connector but is currently operating as a Host (USB0_ID=GND).
    Do not exceed 1K series-R on USBn_VBUS. Currently 2.2K (R43/R27).
    USB1 is currently operating in Device mode, but has a USB Type-A (Host) connector.
    USB Hosts must present >=120uF of capacitance on VBUS, ideally placed close to the connector. This is missing.
    If Dual-Role operation is desired, the correct connector should be used (USB Micro-AB) and capacitance can be limited to 10uF with the understanding that not all USB Devices cant be supported in Host mode. For expanded USB Device support, the correct capacitance should be switched in/out based on mode of operation.
    I do not understand the powering scheme implemented on U4. It appears that DRVVBUS does not directly control VBUS to the USB1 connector.
  • 0 in reply to -DK-
    TI__Genius 10645 points

    DK,

    Thank you for the advice. Customer has corrected the errors on their PCB.  (120uF, Replace 4.7R with 33 Ohm on USB_ID)

    After these amendments, they see change in the signal. As it happens on 14% of the board, and not 100%, customer suspects that it is marginal issues relating to AM3354 (while acknowledging that their configuration is currently out of spec).

    Based on the scope captures below, customer is enquiring if TI has seen similar cases before? Does it suggest any corner cases?

  • 0 in reply to Eddie Koh
    TI__Mastermind 27890 points
    Eddie,
    Please verify that ALL required fixes were applied and re-run the rest. From your message it appears that only 2 were addressed, and one of them incorrectly (USB_ID should be tied to GND via 0 Ohm for Host operation).

    To answer your other question, no, we have not seen reports of the device marginality you report.