• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 199 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.

DM6446_USB

Danny Yang
Prodigy 90 points

Dear all:

           We're testing our hardware board (DM6446 platform) now and got something trouble now.  We got VBUS workaround "delay coming"  (Host mode and no any USB device plugged) now and I track the related discussion before. We still got the same problem after I added GPIO (VBUS switch added) control to our hardware board . By the way, that won't be happened on another board (But sometimes it will ). Can you translate why the VBUS workround "delay coming" happened? Caused by our dirty power (spike current)?Or I need to add some delay time before the DM6446 (VBUS pin delay the system 5V power?). Thanks for everybody support. Thanks a lot.     

  • 0
    TI__Expert 5475 points

    Hi,

    When the device is assuming the role of a Host, it is responsible for furnishing the 5V power on the VBUS line. Assuming that you are connecting the correct cable end when the firmware starts a session, the controller will first detect the state of the ID pin. Assuming that it finds it be low, then it will attempt to source power on the VBUS pin. For this to it will drive an internal signal that has not been bonded out, USB_DRVVBUS. This also generates an interrupt. Since we did not bond out this pin, the board designer probably uses a GPIO pin to control the external power supply. The firmware will drive the GPIO pin high when it receives a USB_DRVVBUS interrupt.

    From the controller perspective, once it attempts to turn on the external power logic and it does not see the power supplied within some short period of time, then it will generate a VBUS error. What this means is that, if the firmware takes long time to drive the GPIO high, then a VBUS power sourcing delay happens.

    Once you know your challenges and also are aware of the application requirement, you can design your system differently (for e.g. you might blindly start driving the GPIO high prior to even start a USB session or ...). What I suspect is that your firmware is busy attending some other tasks and probably took time to drive the GPIO high.

    Best regards, Zegeye

  • 0
    TI__Expert 7435 points

    Danny,

    Sincd you mention it works some times this means that the software configuration for using the gpio to turn on the usb charge pump seems to be correct.  Pl. check that configuration to ensure that it is implemented correctly.

    Beyond the above configuration I feel that this issue could be board related.    The error is generated as the usb controller is indicating that there is no power on the vbus line.

    regards

    swami

  • 0 in reply to swami
    Prodigy 90 points

    HI Swami:

                        It works sometimes when I don't use the GPIO control (but add a 200uF capacitor on VBUS power that closed to DM6446 VBUS line on another hardware board). That mentioned it won't be succeed when used GPIO control. Where can I find the reference guide for the DM6446 with HUB (CY7C65640A) design, I'm not sure if the problem is on the power sequence for HUB/DM6446. Thanks a lot.