[AM335x] USB host mode, DRVVBUS issue

One more thing,

Before USB1_DRVVBUS became LOW, USB1_VBUS (from TPS2051) started falling 5us earlier.

Best regards,

Hayden

Hi Hayden,

The reason is that USB_VBUS does not reach a valid level (>4.6V as far as I remember).

However, why it did not wait 100ms?

Best regards,

Hayden

What is the schematics? Is there an overcurrent sense?

Hi Biser,

There was no OC.

Best regards,

Hayden

It sure looks like OC...especially since there is significant droop on SYS_5V and you mention that the TPS starts falling first.

What OS is this example running?

What is the capacitance of USB1_VBUS?

If the 830us is correct, it doesn't appear to be AM335x HW behavior.

Hi DK,

The OS is Linux.

I will check the capacitance of USB1_VBUS.

And, 830us is correct.

As mentioned, this happens sometimes, not always, not with all boards.

In normal case, VBUS scope capture is as below.

Is there any possibility that AM335x HW works differently?

Best regards,

Hayden

For USB1_VBUS, three capacitors are connected.

10nF, 10uF, 220uF

Best regards,

Hayden

You say this doesn't happen all the time...what is the frequency of the failures?

Do multiple devices fail in this manner?

Do multiple boards fail in this manner?

There are several boards showing the problem.

It happens very randomly, with some specific boards, it is reproduced well.

.

Best regards,

Hayden

When issue happend (USB1_DRVVBUS became LOW), VDDS*_USB1 and currents are measured as below.

[1] VDDS*_USB1

[2] USB1_VBUS current and OC of TPS2051

The peak current is about 350mA, so it is not OC (under 500mA).

Best regards,

Hayden

With supplying external 5V power source to the attached USB device, not using USB1_VBUS, the problem did NOT happen.

So, how can we conclude this issue?

How can we fix the issue with using USB1_VBUS?

Best regards,

Hayden

Is there any resister on the PMIC 5V power rail for VBUS? I think PMIC can still go into OC protect mode even if the current is <500mA, if PMIC design is not correct.

However, as you see with the scope capture, "OC" output from TPS2051 remained HIGH, when the issue happened.

Best regards,

Hayden

So, in this case, is it possible that the USB controller detects it as OC condition, and aborts the HOST mode?

Best regards,

Hayden

I'm not aware of any HW behavior that would cause what you are seeing.

Could you verify that the ID pin is hard-strapped to GND? 0 Ohm or direct connect. The fact that not all boards exhibit this behavior, and the failure itself is intermittent, leads me to suspect an assembly or BOM issue.

Checked that the ID pin is surely grounded with 0 ohm.

Best regards,

Hayden

With the system, USB device is always connected, and cannot be removed, so USB host mode also starts when power is on, and system boot starts.

Below is the explanation about USB controller's operation of HOST mode.

If it waits "100ms" for sensing USB1_VBUS voltage level, it will operate with no problem as HOST mode continuously.

However, it aborts HOST mode after 830us, it is too short time.

Can you guess why the problem happened?

Best regards,

Hayden

According to USB specification, when USB device is attached, before the host sending "SET_CONFIGURATION" command, the device must not consume more than 100mA.

When looking at the scope capture posted here at Jun. 29, it shows current peak of over 300mA.

So, is it possible that the USB controller turn off DRVVBUS, because of the peak current of USB1_VBUS?

Best regards,

Hayden

It is not unusual to have more than 100mA flowing for a few ms after VBUS is turned on or after a USB peripheral is hot plugged.  This is because the VBUS capacitors must be charged.  The USB specification limit of 100mA is a steady state current consumption after the peripheral is attached.  The VBUS capacitor requirements and in-rush current limitations are defined in another part of the USB specification.

The AM335x USB subsystem assumes VBUS is sourced from a current limited power switch controlled by DRVVBUS. The voltage applied to VBUS will drop during a over-current condition and the USB PHY in AM335x will report an over-current condition to the USB controller in AM335x if the VBUS voltage drops below 4.4 volts.  This is the only way the USB subsystem knows there has been an over-current condition.  However, the controller ignores this over-current condition during the first 100ms after DRVVBUS is driven high because it knows the current limited power switch must charge the VBUS capacitors.

I can only think of two things that may be turning turning off DRVVBUS after 830us.

AM335x is reset: Turning on VBUS is charging the VBUS capacitors and the inrush current may be dropping your power supply voltage enough that the reset circuit is detecting a voltage drop and asserting reset to the AM335x device which will cause DRVVBUS to be turned off.  Have you confirmed the AM335x device is not being reset 830us after DRVVBUS goes high?

Software is configuring the DRVVBUS terminal to GPIO mode: If your software is changing the value of the respective conf_usb0_drvvbus[2:0] or conf_usb1_drvvbus[2:0] bits to any value other than 000b, the DRVVBUS terminal would be disconnected from the USB controller and may be de-asserted.  Have you confirmed the value of the respective conf_usb0_drvvbus[2:0] or conf_usb1_drvvbus[2:0] bits after this occurs?

Regards,
Paul

Hi Paul,

When the issue happened,

    there was no system, AM3358 reset,

    there was no configuration bit change by SW.

Thanks and regards,

Hayden

With the hardware, USB0 which is configured as OTG is not used. Just for host mode operation, only USB1 is used.

Is it possible that unused USB0 OTG may affect the initial operation to USB1?

Or, do USB0 and USB1 will work totally independently for each other?

Best regards,

Hayden

Hayden Kim said:

Is it possible that unused USB0 OTG may affect the initial operation to USB1?

Or, do USB0 and USB1 will work totally independently for each other?

From a HW perspective, the ports are independent.

They are completely independent from the hardware perspective, but there could be some dependency in your software.

This issue has not been reported by anyone else, so it must be related to your hardware or software.  You may need to dig into the operation of the USB driver enough to understand where you can place print statements that would help you understand what is happening just before DRVVBUS is de-asserted.

Regards,
Paul

Team,

Please check below internal thread.

https://e2e.ti.com/support/arm/sitara_arm/int_sitara_am335x/f/425/t/357640.aspx

Thanks and regards,

Hayden