• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 4082 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.

AM335x VBUS detection

Steve Gilson
Prodigy 90 points
Other Parts Discussed in Thread: TUSB320, AM3354, AM3352, SN74LVC1G08

Hello,

We're working on a design using the AM3354 for USB OTG on both USB0 and USB1, along with a TUSB320 on each port to interpret USB-C devices and cables and provide the ID pins to the AM3354 .  We're doing some prototyping with the Olimex AM3352 EVM board and the TUSB320 EVM board as well.  We've encountered a few issues so far and would appreciate your help:

1. We've observed the leakage power from USBx_VBUS to VDDA3P3V_USBx as described in another forum post (https://e2e.ti.com/support/arm/sitara_arm/f/791/t/328345).  We are using a separate device, FAN3989, to detect the presence of a USB charger, which is isolated from the AM3354 D+ and D- signals with a USB data switch because the unpowered processor seems to interfere with the voltage on D+ and D- that the FAN3989 looks for.  The leakage power causes the data switch to not isolate, interfering with charger detection when our device is powered off.  To fix this, we would like to add an SN74LVC1G08 AND gate between each VBUS rail and the AM3354's USBx_VBUS inputs.  The Vcc and A inputs of the AND gate are provided by a separate 5V power rail in our system, and the B input connects to VBUS, so the gate drives 5V out to the AM335x when VBUS is on.  However, we've observed on the Olimex AM3352 EVM board that the VBUS input to the processor is not a strictly digital input, but it puts out some short pulses described in another post (https://e2e.ti.com/support/arm/sitara_arm/f/791/t/358092).  Will the AND gate interfere with the VBUS detection in the processor?  Is the processor sensitive to the rise time of VBUS?  We plan to test this on the Olimex AM3352 board but would like your input as well.

2. Separately from item 1, we've been having trouble with the Olimex AM3352 board using the USB OTG port in Host mode.  If we start Linux with a USB device connected to the port (i.e. with the ID pin grounded), the device is enumerated by Linux correctly.  The device can subsequently be removed and reinserted, or the board can be connected to a USB Host, and everything works properly.  Everything also works properly if we start Linux with the ID pin shorted to ground but no device connected.  However, if we start Linux with the ID pin floating, USB devices will never enumerate correctly.  Probing with a scope, in this case we see the ID pin held low when the device is inserted, then USB0_DRVVBUS is asserted high and USB0_VBUS turns on and goes to 5V within 100-200us.  VBUS stays on for just over 100ms, the timeout described in several other forum posts, but then turns off.  The Olimex board is using USB0_DRVVBUS to control the power switch and it monitors VBUS, as required by the TRM and other forum posts.  Are there any known issues that could explain this behavior? 

Thank you for your help,

Steve

  • 0
    TI__Guru**** 393215 points
    Hi,

    1. USBx_VBUS is an input on AM335x. I'm afraid we cannot help further without seeing the schematic.
    2. Olimex AM3352 board is a third-party product, not developed or tested by TI. We cannot comment on it's behavior.
  • 0
    TI__Mastermind 27890 points

    Hi Steve,

    1) Are you trying to use true USB-OTG or USB DRD (Dual Role Device). The primary difference is that in DRD, dynamic role-reversal is not supported. In other words, if we enumerate as a Host/Device, we remain a Host/Device for the entirety of the session.

    2) There are 2 controller VBUS state-machine checks prior to asserting USBn_VBUS:

    1. Prior to asserting USBn_DRVVBUS, the controller will check to see if VBUS is already present via the USBn_VBUS input. If so, the controller will not assert DRVVBUS to prevent VBUS contention (only Hosts provide VBUS and Host to Host connections are not supported in USB).
    2. When acting as a Host, USBn_VBUS must reach >4.1V within 100ms of our asserting USBn_DRVVBUS or the controller will assume the VBUS power supply is OC and will de-assert DRVVBUS. In your case, given the observed ~100ms timeout, it appears the controller doesn't see >4.1V on the relevant USBn_VBUS input.
  • 0 in reply to -DK-
    Prodigy 90 points

    DK,

    Thanks for your answer.  For OTG, we want to be able to have successful OTG host and peripheral sessions.  We are willing to live without SRP/HNP.  We have successfully established host and peripheral sessions with the Olimex board, but host sessions only functioned if the board powered up with the ID pin grounded.  We suspect this could be a software/driver bug so we're not too worried about it right now.

    Our real concern is not with the Olimex board but with our custom hardware.  On USB0, when we insert a USB device we observe the ID pin go low, but USB0_DRVVBUS is never asserted, and therefore USB0_VBUS isn't turned on - we are using DRVVBUS to control a power switch.  On our hardware, ID is driven low by the TUSB320 and has a 200k pullup (I know that the AM3354 doesn't want a pullup on that pin - we installed the pullup before we saw that note - we will remove the pullup, although the Olimex board works with it present).  Our pinmux is configuring the DRVVBUS pins as DRVVBUS, not as GPIO (pin 135 (44e10a1c.0) 00000000 pinctrl-single; pin 141 (44e10a34.0) 00000000 pinctrl-single).  Below is a scope capture of plugging in the USB device.  VBUS is low before insertion - the pulse is from the processor sensing the pin, we see the same pulses on the Olimex board.  Is there any other reason that the AM3354 would not assert DRVVBUS in response to ID being grounded?

    Thanks,

    Steve

  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points
    I have an update to my prior comment regarding TI Processor SDK for Linux 03.00.00.04: I have seen host and peripheral operation on the Olimex AM3352-SOM-EVB OTG port (i.e. mode is set to otg).

    Similar to 02.00.02.11, there appear to be inconsistencies but I have observed the port establish a host connection without the ID pin being grounded during initialization. For example; I was running the 03.00.00.04 arago-base-tisdk-image build and accidentally did the following sequence: powered up without anything inserted in OTG port, inserted USB flash drive, while I still had a flash drive connected to the OTG port:
    umount /run/media/mmcblk0p1; modprobe g_mass_storage file=/dev/mmcblk0p1

    That is when the flash drive was recognized and mounted.

    I then umounted the flash drive and when the PC connection to the Olimex was inserted, the g_mass_storage module drive was presented to the PC.