• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 348 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.

AM3505 USB0 peripheral

Alex Shpilsky
Intellectual 1000 points
Other Parts Discussed in Thread: AM3505

We are trying to use USB0 in host-only mode (no OTG required) and we are I/O constrained in our interfaces.  Therefore, we are really only using D+/D- and providing the control for the +5V at the port by other means.  The result of those design choices was to leave: USB0_DRVVBUS, USB_ID and USB0_VBUS all no-connect.

To my understanding USB0_DRVVBUS is an output that I don't need so perhaps it doesn't matter, USB0_ID is for negotiating a/b side and perhaps can be ignored by the VxWorks driver, but USB0_VBUS might need to be 5V for the peripheral.  Can you find out or put me in touch with someone who knows.  I looked at the datasheet and the technical reference manual and did not find this level of detail for the USB0 peripheral.

 

  • 0
    TI__Mastermind 27890 points

    Alex,

    The USB_ID must be strapped low for Host-only mode to ensure proper functionality of the USB core.

    As for the other pins, the host the controller expects to have full control over VBUS. This is accomplished via the DRVVBUS pin, which should be used to control the output enable of a 5V power supply, and the USBx_VBUS pin which is used to sense the state of VBUS. Keep in mind that this device does not have a dedicated VBUS over-current pin, so this (and other) functionality is baked-in to the USBx_VBUS pin.

    Leaving any of these pins unconnected is not a supported configuration.

  • 0 in reply to -DK-
    Intellectual 1000 points

    I understand not a supported configuration.  Unfortunately, that is not the best solution for our embedded application.  The 5V power supply is not on the same board as the AM3505 and we are pin constrained so we cannot bring it back to the AM3505 board.

     Can I get more information on the limits here regarding DRVVBUS and USBx_VBUS?  Can I pacify the USB peripheral by giving it another fixed +5V reference all the time?

    Thank you,

  • 0 in reply to Alex Shpilsky
    TI__Mastermind 27890 points

    Sure.

    When in Host mode, the controller will drive DRVVBUS when the session is started. It expects to see >=4.4V on the associated VBUS_IN pin within 100ms. If this voltage level is not present within this time period, the controller will assume the power switch is in OC mode and will clear the session bit, disabling the interface. Conversely, prior to asserting DRVVBUS, the controller will check that VBUS is not already present to prevent contention. If VBUS is >=4.4V prior to the controller driving DRVVBUS, the controller will clear the session bit, disabling the interface.

    Please keep in mind that at its heart, this controller is a USB-OTG controller rather than a pure Host or pure Device and as such there are trade-offs that need to be made when designing and implementing such a device. Requiring complete control over VBUS is one such trade-off.

  • 0 in reply to -DK-
    Intellectual 1000 points

    Good stuff!

    Any possibility of a software work-around you might have laying around?  We will make the design improvement regarding DRVVBUS and VBUS_IN in the next spin of the hardware, but if you have a code sample or recipe to allow us to test these prototypes we'd make some progress in the meantime.

     

  • 0 in reply to Alex Shpilsky
    TI__Mastermind 27890 points

    There is no SW workaround for either VBUS_IN or USB_ID in your usage scenario.

    You may be able to get by (as a test only) with tying VBUS_IN to an always-on 5V source, strapping USB_ID directly to GND, and leaving USB_DRVVBUS floating. There would, of course, be no OTG or Peripheral functionality in this configuration. Please keep in mind that depending on the USB socket you have on your board, that there may be nothing preventing someone from plugging another host into your host, at which point both would be sourcing 5V since you are not using the DRVVBUS protection/functionality.

    *EDIT* By 'always-on', I mean a board 5V supply that is not controlled by the DRVVBUS pin.