Just wondering if I can get some clarification on the internal operation of the ID pin for the USB. The datasheet only has a single line reguarding its operation.
We are trying to get the OTG functionality working and looking at the ID pin, it wants it either grounded or floating, but no pull up on the line. It doesn't appear the is an internal pull-up either. How does this actually end up working out, is there a very low voltage comparitor or what? It seems strange because for normal device/host mode per the eval kits, you pull the line up/down.
Also, it implied that it looked at this pin to determine which mode to power up in, but the USB cable could potentially be plugged in and tie the ID pin to ground after the USB module is up and running, does the module need to be restarted? If so, where/how can the ID pin be monitored, as I'm not seeing a register address to accesss the state of this input.
Thanks for any help you can give.
You are correct, USB_ID should be pulled up via 10K resistor. USB_ID status is reflected in DEVCTL.BDEVICE register bit; see USB UG for more detaisl (http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprued2c)
On the link you sent, it says "If using OTG or mini-USB connector, this pin will be set properly via the cable/connector configuration". It doesn't say to pull up/down this line. But the cable connects the ID pin to ground for host mode and leaves it floating for device mode.
Further, the357 usb users guide (http://www.ti.com/litv/pdf/sprugh3) says the pin should be open or tied to ground via cable.
I do realize what the document suggests, but have verified with our factory team that indeed a small pull-up resistor is needed on USB_ID pin. We will correct the documentation. Also, I referred you to the doc more for the register settings, acknowledging the USB_ID pin suggestions are incorrect. Thank you for your understanding.
Could I also suggest that a note be added to the USB User Guide describing that the state of the USB ID pin can be read from the DEVCTL.BDEVICE bit. The only reference to the ID pin in that document is the pin description and the register itself just says that it tells what state the USB controller is in, not that is determined its state from the ID pin.
Mike, sure thing. This sounds like a reasonable request.
I assume your are discussion about DaVinci USB Controller. Can you specify which particular DaVinci Device are you refering to?
The ID pin is used by the USB controller to determine the intented role that the controller has to switch to depending on the end of the cable that gets plugged into the USB connector.
The fact that you are trying to test OTG the ID pin should be directly connected to the USB controller ID pin on the DaVinci device. Pl. refer to the DVM schematics for the same.
I'm using the DM357.
I do have the ID on the DM357 tied to the ID pin on the connector. The issue is if the ID pin should be pulled up or left open as refered from the user guide. Juan mentioned the documentation is in error and the ID should be pulled up via a 10k resistor.
Just to be clear, the value of the resistor is not strict, you need a small pull up resistor. I have seen anywhere from 1.5K to 20K being suggested, but I know a customer that actually implemented this using a 10K, thus my recommendation.
Remember that the USB ID pin is pin4 on the cable and this pin is either joined with pin5 (ground) or left unconnected (floating). The mini-A connector grounds the ID pin with Ground pin so that the ID Pin state is low. Up on seeing the state of the ID pin being low, the USB controller responds by assuming a Host role. If it is left floating, you need to have a weak pull-up so that the ID pin is High and the USB controller will respond by assuming the role of a Device.
I tried reading the BDEVICE register to see if the ID pin is pulled high or low, but it does not reflect the current state of the pin. It does mention it is only valid when the session is valid.
Is there any way to get the status of that pin without a session or somehow fool the controller into thinking there is a valid session so it will latch the state of the pin?
There is no need to monitor the ID pin to understand the state on DM35x, DM644x, DM646x, OMAPL13x platforms,
You need to set the session bit in the controller. In response to this the controller will do the required ID pin sense and appropriately generate either
The later 2 cases signify Device mode while the 1st scenario signifies Host.
Another interrupt you need to be aware of is the SRP interrupt that will be raised when a OTG cabapable device is connected and it requests for the VBUS to be turned on. In this mode you again are in Host mode and would respond to the SRP interrupt by turning on the VBUS charge pump, afterwhich the regular process of enumerating the device proceeds.
Pl. refer to the Linux USB driver for reference. All these sequences are implemented and well tested at the least on DM35x platforms.
I just ran into one more interesting thing reguarding the USB interface.
I added some ESD protection to the USB lines using a NUP4201 device from NXP.
It contains a TVS diode for power line protection and fast diodes for transiant supression of the data lines.
I connected the power pin on the transient protection circuit to VBUS to hold the data lines within VBUS and ground (within a diode drop), but... because my OTG device switches VBUS on and off, when the VBUS is switched off I actually measure ~2.5V on my VBUS line due to the required bias of the ID line to 3.3V.
I'm wondering if the ID pin on the DM357 is 5V tolerant so I could use VBUS to pull up the ID pin rather than 3.3V. Otherwise, is there any reason I couldn't use a voltage divider from VBUS to ground connecting the middle net to the ID pin on the connector and the device if I create a voltage at the ID pin of ~3.3V referenced from VBUS.
I guess my last option would be to add a second surge suppression circuit limiting the ID pin to 3.3V, this is probably the best option, but not something I'm really wanting to do.
Anyhow, thanks for the feedback in advance.
when USB Device mode on DM644x,when should I set the DEVCTL.BDEVICE to initate a SRP on the USB bus,and when connect to Windows,how can make Windows find a new device?
You should be setting the session bit to initiate SRP when connected to B end of cable. When you connect to PC -host, PC-host would start of resetting DM644x device and you would not have to do anything in this case.
Think you for your replay.But how can my program detect the connection of the B end of cable and DM644x?
Can you explain you exact usage context ?
In the context of OTG one would not need to know the state of the cable end connected. The controller along with the underlying driver takes care of this. All the application has to do is to ask for a session.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.