• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 100 subscribers
  • Views 3369 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.

USB_VBUS & USBDRVVBUS in DM365

Dvir
Prodigy 80 points

Hi,

 In my project I'm using DM365 as USB host to an on board USB device that doesn't use 5V supply (uses 3.3V).

 I read in previous post that I will still need to supply 5V to VBUS, I got 4.5V-4.8V supply, what is VBUS threshold for detection?

 In the USB user guide it is written that USBDRVVBUS is used to control the 5V supply – since I don’t need it – what to do in this pin?

 Pull down? Leave it unconnected?

Regards,

Dvir

  • 0
    TI__Expert 5475 points

    Hi,

    When operating as a Host, it is the Host's responsibility to furnish power on the VBUS line, regardless with the Device being self-powered or bus-powered.

    Having said that, a USB Component  (whether it is Device or Host) is in Session if the VBUS Voltage observed by the Component is >= 4.4V. This Voltage Level is referred to as VBUS Valid. The Host needs to insure that the Power it is supplying is high enough that the voltage measured at the Target pin should be >= 4.4V. This power when measured at the Host side should be at least 4.7V. So, 4.8V would work but 4.5V would not work most of the time, unless the cable is very short.

    The USB_DRVVBUS is used by the USB Controller to enable/disable the external Power Supply when the USB Controller assumes the role of a Host. If you do not have a dedicated P/S that needs to be truned on when operating as a Host and is disabled when not used as a Host, then you will have no use for this signal. The USB Controller only desires to see a >4.4V on VBUS line and it does not care as to where the Power is being sourced from. The pin is multiplexed and you can use the pin for task other than USB related. If you have no desire to use this pin and need to insure that it is not oscillating and drawing power, then you can pull it high or down.

    Best regards, Zegeye

  • 0 in reply to Zegeye Alemu
    Prodigy 80 points

    This is very helpful,

    Thanks,

    Dvir

  • 0 in reply to Zegeye Alemu
    Intellectual 330 points

    Hi I have e a problem with I board I have designed: I can not make the USB working. The DSP is usb host, and it is connected to an external hub. The USB_VBUS is connected permanently to 5 V and the ID is tied low thru a 1.5 k resistor.

    The DSP does not get the DRVVBUS interrupt, and when it checks the DRVVBUS bit in the status register, it tell him that it is low - i.e. not asserted.

    Now, who asserts drvvbus? And mustn't i take it out to gpio33? I am very confused about this

    What is the correct sequence to activate the bus as host?

    Thanks

  • 0 in reply to Dvir
    Intellectual 330 points

    Dvir, would you  mind to be in touch with me directly?

    I am albertbu@gmail.com - I may have a question or two for you.

    Thanks

  • 0 in reply to albertburbea
    TI__Mastermind 19985 points

    Hi,

    I think Zegeye has given a very clear explaination on how the USB host controller works.

    DRVVBUS is asserted when the session is started on the host side. But as Zegeye mentioned, if you have a separate power supply driving 5V always connected to the USB bus, you really dont need to worry about DRVVBUS. It is a logic for the host to control, when to drive 5V on the bus. In your case, it seems you are always having 5V.

    For the other question you had about GPIO33, the idea is that DRVVBUS is controlled by the USB controller. The controller drives DRVVBUS and deasserts it again within a fixed time duration (based on USB standard), in case there is no activity on the D+ line from the connected device. This is meant to save power. Now, to override this mechanism of automatic deasserting, we have given an option to the user to use GPIO33 instead of DRVVBUS signal to drive the 5V on the bus. This way, user has control on how long we want the 5V supply driven on the bus. This would help if you have devices that take longer to respond to D+ etc.

    Hope this helps.

    Regards,

    Anshuman

    PS: Please mark this post as verified, if you think it has answered your question. Thanks.

  • 0 in reply to Anshuman Saxena
    Intellectual 330 points

    Hi Anshuman, 

    my main issue is: how does the USB controller become a host? Does it depend on the USB_ID pin only, or on other conditions? I can not see the HOST bit in the USB STATUS register go high. I need to fully understand the process to debug my board, and of course this is urgent

    What can be the problem ? ?? ?

    10x 

    Albert 

  • 0 in reply to albertburbea
    TI__Mastermind 19985 points

    Hi Albert,

    Following things need to be ensured to get HOST bit showing "1" to you.

    1. I assume you are having an external power supply that is not controlled by USB_DRVVBUS and is always on at 5V. You should have USB_VBUS pin connected to this 5V supply.

    2. USB_ID pin is connected to "0"/GND.

    3. Enable session by setting the SESSION bit in DEVCTL register.

    Once you ensure all the above are fine and an active SESSION is setup (SESSION bit is set to 1), you can read HOST bit in DEVCTL register.

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    Intellectual 330 points

    Hi

    I have verified all this = all the connections  seem correct, but yet the USB  controller identifies as a slave (99 in devctl register). Host bit is low

    Any ideas?

  • 0 in reply to albertburbea
    TI__Expert 5475 points

    Hi,

    If the SESSION bit is set, which seems to be the case, and the DEVCTL[BDevice=Bit7] is set, then the core is configured as a Device not Host.

    Are you sure the ID pin is grounded? Do you have a pull-up resistor on the ID pin (please remove if have one) and then you can ground it yourself externally. Leave the ID pin floating if state of ID pin is controled by the cable end (ensure that you are inserting a mini/micro-A side) or you ground it yourself.

    One other question is who is generating the power? DEVCTL[VBUS{1:0}]=11b and this is the right voltage level. Are you supplying the voltage full time or do you allow USB_DRVVBUS turn on the Power Source? If the controller is operating as a Device, it will not drive the USB_DRVVBUS high. Please check your power source control.

    Also check if you are getting a USB_DRVVBUS interrupt after setting the DEVCTL[SESSION] bit?

    Best regards, Zegeye

  • 0 in reply to albertburbea
    TI__Expert 5475 points

    Hi,

    If the SESSION bit is set, which seems to be the case, and the DEVCTL[BDevice=Bit7] is set, then the core is configured as a Device not Host.

    Are you sure the ID pin is grounded? Do you have a pull-up resistor on the ID pin (please remove if have one) and then you can ground it yourself externally. Leave the ID pin floating if state of ID pin is controled by the cable end (ensure that you are inserting a mini/micro-A side) or you ground it yourself.

    One other question is who is generating the power? DEVCTL[VBUS{1:0}]=11b and this is the right voltage level. Are you supplying the voltage full time or do you allow USB_DRVVBUS turn on the Power Source? If the controller is operating as a Device, it will not drive the USB_DRVVBUS high. Please check your power source control.

    Also check if you are getting a USB_DRVVBUS interrupt after setting the DEVCTL[SESSION] bit?

    Best regards, Zegeye

  • 0 in reply to Zegeye Alemu
    Intellectual 330 points

    Hi Zegeye,

    THe voltage VBUS is stable well before the DSP boots and is not controlled by anything. Also, I am not getting any DRVVBUS interrupts. I have only a pull-down on the USB_ID . I recevie only this interrupt IRQ SOURCE= 0x00010000 and I tinnk it means "suspend"...

    THanks

    Albert

  • 0 in reply to albertburbea
    TI__Expert 5475 points

    Hi Albert,

    There is something going wrong here for sure. Suspend Interrupt is OK and is expected. However, you should have seen USB_DRVVBUS interrupt, even if you are not using it. What is the Device you are working with; I am wondering if the USB_ID pin is bonded out. Some of our devices do not have this pin bonded out due to shortage of pins and we use register fields to control the state of the pin.

    Best regards, Zegeye

  • 0 in reply to Zegeye Alemu
    TI__Expert 5475 points

    Hi Albert,

    I see that this is the DM365 device. It has the USB_ID pin bonded out. The Device is thinking that the state of this pin is not Grounded. Since it is observing power on the VBUS pin and it is seeing that the USB_ID pin is not grounded, it thinks that it is a Device and an external Host is supplying that VBUS power.

    Got to trust me on this, your issue is with the ID pin. Whether it is by the connector or somewhere on the board, your ID pin is not grounded. Are you using a driver or a small test code?

    Best regards, Zegeye

     

  • 0 in reply to Zegeye Alemu
    Intellectual 330 points

    Hi

    I trust you Zegeye, also because this was also my conclusion. Now: I have measured the USB_ID pin impedance with a DVM, and it is around 20kohm - is this acceptable?  I am using a driver for USB controller - I have added some printk and this is how I reached this conclusion. The USB_ID pin was floating for a while - do you think is may be damaged?

    Of course now is grounded by a 4.87k resistor

    Is there a way in software to "force" the controller to believe that USB_ID is grounded - aka that the controller behaves like a host ?

    Thanks a lot for your help

    Albert

  • 0 in reply to albertburbea
    TI__Expert 5475 points

    Hi Albert,

    If it is floating, then it is going to assume the role of a Device. Try to blue wire it directly to ground. I don't want to go through this discussion but to briefly mention it here is that the way the PHY detects the ID pin state is not by Voltage but by Resistance. That is the reason why we are telling customers to not pull-up the ID signal to any voltage rail no matter how weak the pull-up resistor is. So, the ID signal should remain floating and the Micro-Mini-A Connector will ground it. I suggest you remove the 4.7K Ohm and ground it directly.

    I looked into the PHY Control Register, USB_PHY_CTRL (this is available within ARM SubSystem Guide) and I see no option of controlling the state of the USB ID pin from Register. So, forcing the state of the ID pin is not available on this device.

    What this means also is that, you need to insure the ID pin state is in the right state PRIOR to the USB going into Session.

    Best regards, Zegeye

  • 0
    TI__Expert 5475 points

    Hi Dvir,

    You need to be careful with this signal. Not sure if the USB_DRVVBUS on this device is multiplexed with other peripheral. Assuming that it is not and this siganl is available for the use of the USB, the USB controller is always going to drive this signal high to enable an external p/s when assuming a role of a host. It will drive it low when it is operating as a Host and is ending a session or when it assuming a role of a device.

    Now, having said that, if you are using the USB regardless of the role of operation it uses, we suggest you leave this signal not connected. If you desire so long as you pull it high or low via resistor it is OK. Make sure you do not tie it directly to a voltage rail.

    I think you might be missing the use of USB_DRVVBUS and VBUS. VBUS is one of the USB pins that is going to be extended to the connector and this pin should have a power with a voltage level of > 4.4V. The VBUS pin on our device will use this voltage to enable the 1.5K Ohm pull-up Resistor within the PHY when operating as a Device. This voltage is also used as a handshake protocol between the Device and attached Host to signify to the Device a presence of an external Host. The signal level should be above 4.4V. The PHY will continually monitor for this voltage level and if it is below 4.4V, you are going to get a VBUS error. Our devices are not bus powered devices and do not use this voltage other than the use mentioned above. But remember one of the use is for detecting host presence and if this signal level is below 4.4V, it is not going to work. So, our VBUS pin can be thought of as a Voltage Sensing Pin. Bus powered devices do more than sensing to this voltage but that is not how our device operate.

    When operating as a Host, the PHY will still monitor the voltage level on the VBUS pin to insure that adequate power is supplied to an external device. So, still it is going to require that the voltage level on the VBUS pin is at a VBUS VALID range which is > 4.4V (infact to account for the voltage drop you require it to be at least 4.7V or above). This is when the USB_DRVVBUS is used, so tha an external power supply is enabled to furnish this 5V power. Remember that host is the one providing power.

    In summary, if you do not use this signal and you are using the USB it is recommended you leave this signal not connected. If you are not using this signal to control a p/s or charge pump you can pull it high or low via a Resistor and that is fine or you can leave it not connected. It will be driven high or low and will not be oscillating or toggling. The email trail you referenced was furnishing power full time so VBUS pin always sees 5V voltage. That is fine. This is similar to a PC Host where this voltage is always available.

    Best regards, Zegeye