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: About USB VBUSERROR and DRVVBUS

Part Number: AM3352

Hi,
We have a question from one of our clients.
They are using AM3352 as a USB host.

1, What is the cause of VBUSERROR interrupt?
In the TRM (SPRUH73Q) chapter "16.2.7 USB Controller Host and Peripheral Modes Operation", it states "After 100 ms, if it does not see the voltage on the USBX_VBUSIN pin to be within a Vbus Valid range (>= 4.4V), it will generate a Vbus error interrupt".
Also, in E2E (e2e.ti.com/.../am3354-is-it-possible-to-keep-usbx_drvvbus -high), "When VBUS drops below VBUSVALID, the MUSB controller turns off DRVVBUS and generates a VBUSERROR interrupt".
Are there any other causes of VBUSERROR interrupt?

2、What causes DRVVBUS to go Low?
It goes Low when VBUSERROR occurs.
They think that the USB Controller also detects an abnormality when an overcurrent occurs after startup, and sets DRVVBUS Low.
If this is certain, please let me know the conditions (voltage/current, etc.) under which it is determined to be an overcurrent.
Also, if there are other factors, please let us know those as well.

Best Regards,

Kouji Nishigata

  • Hi,

    In the TRM (SPRUH73Q) chapter "16.2.7 USB Controller Host and Peripheral Modes Operation", it states "After 100 ms, if it does not see the voltage on the USBX_VBUSIN pin to be within a Vbus Valid range (>= 4.4V), it will generate a Vbus error interrupt".
    Also, in E2E (e2e.ti.com/.../am3354-is-it-possible-to-keep-usbx_drvvbus -high), "When VBUS drops below VBUSVALID, the MUSB controller turns off DRVVBUS and generates a VBUSERROR interrupt".

    Yes, this is the cause - if the USB controller at a point of time expects to see VBUS_VALID on VBUS line and don't sense it, VBUSERROR interrupt is generated.

    Are there any other causes of VBUSERROR interrupt?

    No.

    2、What causes DRVVBUS to go Low?
    It goes Low when VBUSERROR occurs.

    Yes, VBUSERROR is one reason. Other reasons are

    - BABBLE interrupt

    - software decided to leave USB host mode

    hey think that the USB Controller also detects an abnormality when an overcurrent occurs after startup, and sets DRVVBUS Low.

    No, MUSB controller and its PHY doesn't detect overcurrent, since they are not sourcing VBUS power.

  • Hi,

    Thanks for your answer.

    I have an additional question from them.
    It says that if the USB Controler is operating in HOST mode and the voltage drops below VBUSVALID, it generates a VBUSERROR interrupt.
    Assuming VBUSVALID is 4.4V, what is the time frame?
    Does it occur at the moment the voltage drops below VBUSVALID? Or does it occur after a certain period of time, like at startup?

    Best Regards,

    Kouji Nishigata

  • Assuming VBUSVALID is 4.4V, what is the time frame?
    Does it occur at the moment the voltage drops below VBUSVALID? Or does it occur after a certain period of time, like at startup?

    It occurs right after the USB PHY senses the VBUS drop.

  • Hi,

    We were told by a client of the phenomenon that gave rise to this question.
    Regarding the two diagrams attached, C1 is the current on VBUS and C2 is the voltage on VBUS. They are electronic loads causing an overcurrent on VBUS.

    In the first figure, the current is 0V immediately after the overcurrent occurs, which suggests that an interrupt has occurred and is being handled.

    However, occasionally, they are experiencing a phenomenon where the current is held for nearly one second, as shown in the second picture. Do you have any ideas as to what might be happening with these phenomena? Or is there anything we should look into?
    We are trying to adjust if it is possible for the customer to see the timing of the interrupt in GPIO after it occurs.
    They are also using SDK Linux 04.03.

    Best Regards,

    Kouji Nishigata

  • Hi,

    We received a diagram from a customer with the timing of interrupts output via GPIOs.


    CH1: BUS current
    CH2: USBx_BUS voltage
    CH3: VBUS_ERROR interrupt (remains high after the interrupt occurs due to software reasons)
    CH4: USBx_DRVVBUS

    When an electronic load causes an overcurrent (rising edge of CH1), the USBx_BUS voltage drops to 4V, but the CH3 interrupt occurs 1 second later.
    This seems to be a different behavior from the previous specifications, what is considered to be the situation?

    Best Regards,

    Kouji Nishigata

  • Hi, 

    To me it doesn't look like Processor is working according to the specs when I look at this waveform.
    Please give me a response to see what is going on and if there is anything to look into.

    Best Regards,

    Kouji Nishigata

  • HI,

    As I wrote in the last issue, the graph suggests that it is not working according to specifications. Can you please provide some insight into this, including the possibility of a malfunction?

    Best Regards,

    Kouji Nishigata

  • Hi Nishigata-san,

    Does the issue happen after the USB device is already enumerated and is under normal USB operation? Or does it happen during inserting the USB device?

    What is "an electronic load" which causes the overcurrent condition?

    USB2.0 Spec requires the USB VBUS line should have minimum 120uF CAP, is it present in your design?

  • Hi,

    Thanks for the response.

    First of all, they have a USBdevice (dongle) plugged in, which sometimes causes a VBUS error during startup and sometimes falls off during operation.
    To check for this VBUS error, I have connected an electronic load device between USB GND and VBUS and shorted it in constant current mode (settings are in the picture title). At this time, there is no device or other device connected to the USB/no load.
    The CAP is C14:150uF.

    The customer has given me a schematic and measurement points around the USB, but he is not allowed to publish them. Can I send them to you via private message? Or how can I upload the diagram?

    Best Regards,

    Kouji Nishigata

  • Hi Nishigata,

    I am routing your query to our USB hardware expert for comments.

  • Hi,Bin Liu 

    Thanks for the reponse.
    Please support us.
    I have written a schematic in private message.
    Please refer to it if necessary.

    Best Regards,

    Kouji Nishigata

  • Hi,

    The development of this matter has been halted by our client and we are in a hurry.
    We would like to receive some updates by tomorrow.
    Please do not hesitate to contact me.

    Best Regards,

    Kouji Nishigata