• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 521 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.

AM3352: Recover from USB VBUS error

Tony Tang
Mastermind 29122 points
Part Number: AM3352

Tool/software:

As in the TRM, VBUS<4.4 generate VBUS error interrupt. 

After then VBUS error interrupt, doesn't response to USB flash inserting, detaching anymore, need to power cycle the board to recover. 

How to recover in software, no need power cycle?

for example, which register to reset, etc....

Further experiments:

If keep VBUS=4.2V, insert/detach MSC U flash can always successful, but if has voltage drop during insertion even drop to 4.6V, also trigger VBUS error and result can't recover. 

The Yellow line is VBUS, drop to 4.6V during inserting MSC U flash.

  • 0
    TI__Guru**** 168421 points

    Hi Tony,

    The USB Specification requires USB host should have minimum 120uF CAP on VBUS close to the USB port. Does this CAP exist on the custom board?

  • 0 in reply to Bin Liu
    TI__Expert 3595 points

    Hi, Bin

    Thanks for help.

    Customer checked and there is no 120uF on board, which is indeed a design defect, but there are two questions that have not been explained clearly:

    (1) It can work normally at 4.2V, and it will also trigger an abnormality when it drops to 4.6V. What is the reason?

    (2) What is the trigger response time of this voltage drop? It can trigger an abnormality when it is less than 100us.

    (3)Can we mask the VBUS monitor function by software to avoid this issue?

    Regards

    Zekun

  • 0 in reply to Zekun Bai
    TI__Guru**** 168421 points

    Hi Zekun,

    Zekun Bai said:

    (1) It can work normally at 4.2V, and it will also trigger an abnormality when it drops to 4.6V. What is the reason?

    (2) What is the trigger response time of this voltage drop? It can trigger an abnormality when it is less than 100us.

    The VBUS sensing is an analog circuitry in the SoC, I don't have its visibility to answer your questions. The processor is expected to work correctly only when the hardware design doesn't violate the USB Specifications (the >120uF CAP in this case).

    Zekun Bai said:
    (3)Can we mask the VBUS monitor function by software to avoid this issue?

    The kernel USB driver does check the VBUS error interrupt and recover when the issue happens. However, the driver doesn't retry forever, so in some scenarios with different timing of the VBUS drop, the software recover might not resolve the problem.

  • 0 in reply to Bin Liu
    TI__Expert 3595 points

    Hi， Bin

    Customer have add 120uF CAP on board but they can still see the error. 

    They test 5V supply, and it can reproduce at a lower frequency. 

    4.2V supply, test for hundreds time, can not reproduce the issue.

    Can we try to enable SOC to retry to connect to USB, not waiting all the time. 

    Or can we change the power supply?

    Regards

    Zekun

  • 0 in reply to Zekun Bai
    TI__Guru**** 168421 points

    Hi Zekun,

    The USB Specification requires the USB devices should not have more than 10uF capacitance to prevent too much VBUS drop during insertion.

    I am a sw buy and don't know how to measure the capacitance of the USB device you use. But if you have the VBUS drop issue with multiple different USB devices, you might want to the check the power rail on your board to the VBUS power switch.

    Zekun Bai said:
    Can we try to enable SOC to retry to connect to USB, not waiting all the time. 

    If the VBUS drop issue is caused by device insertion in-rush current, retry in software won't be able to resolve the problem, since the VBUS will drop again after software tries to turn on the VBUS switch. You would have to figure out how to fix the problem in hardware.