Post Go back to editing

USB0_VBC too slow on custom board


We're using your SC587 in a custom design which has a TI TPS25833 for USB-C power delivery. 

The LD_DETn pin of the TPS25833 is connected to the USB0 ID pin on the CPU. 

The USB0_VBC is connected to the enable pin of the TPS25833, but this doesn't seem to work correctly:

The VBC pin stays high for 100ms and low for 50ms. The 100ms is too short for the TPS25833 to generate 5V on the USB connector. I've been looking a way to patch the kernel to increase this 100ms but have been unable to. Can you point me in the right direction? 
However, I'm not entirely sure this is the way to go. It seems the 100ms is defined in the USB specification: TA_WAIT_VRISE should be max 100ms..
A better solution might be to disconnect the VBC signal entirely and keep the TPS25833 enabled by default. This seems to work fine. 
I only need to patch the kernel to stop showing the 'VBUS error recovery' when the TPS25833 isn't generating 5V because no device is detected.. 
What do you suggest?

Another question:

Keeping the TPS25833 enabled works fine if I set CONFIG_USB_MUSB_HOST=y. If I set CONFIG_USB_MUSB_DUAL_ROLE=y instead, and do 'modprobe g_serial' to get the port working as host, the USB0_VBC pin always seems to stay low, so I definitely need to disconnect it.. 
After disconnecting VBC and after loading the g_serial module, the usb stick shows up fine. But If I then disconnect it, I get a 'vbus error recovery' (didn't do the patch suggested above to remove these messages yet) and the usb stick won't be detected again until a reboot. Only if I unload the module before disconnecting, and modprobe g_serial again, the USB stick will be discovered.
modprobe g_mass_storage to test the USB0 port as a device seems to work fine all of the time. 

This all seems a bit strange to me.. I got this all from the old linux add in user guide.. I'm using Yocto to build our distro. Maybe there's some updated documentation? 


  • Hi StijnVM,

    I could see our default USB-type B port have Mosfet switch to trigger, As you moved to the regulator,

    For TPS25832-Q1, the pin voltage must meet the requirement below during 150-ms (typ) Rd assert deglitch.
    According to
    The vbus will be up to 150ms to enable the trigger,
    But our #define TA_WAIT_VRISE (100) is set to 100ms, which causes the issue, I believe.
    Could you try increasing the TA_WAIT_VRISE value to 150 or above and give it a try by rebuilding the kernel?
    Prasanth R
  • Hi

    I can find 2 TA_WAIT_VRISE defines in the kernel source: in otg_fsm.h and phy-fsl-usb.h. 

    None of those are used in the build: CONFIG_FSL_USB2_OTG and CONFIG_USB_CHIPIDEA are both off.

    So this seems to be defined somewhere else, but I can't figure out where .. Slight smile

  • Hi StijnVM,

    suggestion from our USB Engineer:

    TI chipset is making 150ms turnaround time to sense EN pin and raise VBUS to 5V(As mentioned in their datasheet). But as per USB-OTG specification expected VBUS raise time is 100ms.
    My assumption is USB SW could continuously monitor the VBUS status after turn-on through USB0_VBC. Since the VBUS is not reached 5V in 100ms, it may sense this as a faulty case and attempts to turn off VBUS through USB0_VBC after 100ms.

    So, the Workaround can be to disconnect the USB0_VBC to EN and enable the EN pin in some other way.

    But the only problem in this approach is, if in any case user application or USB stack wants to control the VBUS in any faulty situations or application demands, there is no way to do this other than controlling the VIN (actual VBUS) connected to the TI chip.


    Prasanth R

  • Hi 

    Thanks for your reply. We will probably take the same approach. 

    Could you also take a look at my other original question, regarding setting CONFIG_USB_MUSB_DUAL_ROLE=y ?

    Many thanks!