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.

AM335X USB0_DRVVBUS automatically switched to low

Hi,

I'm using AM335x USB0 as one Host. The OTG_ID is pulled ground, and the USB0_DRVVBUS is connected to one external USB power switch. 

Currently we are encountering one issue during ESD. When the discharge is to ground or shield, the USB0_DRVVBUS sometimes automacially swiches to the low to swich off the power switch. I didn't see much introduciton about the DRVVUS behavioral during abnormal event. 

I tried to turn off the VBUS detection , but the issue still happens. Don't know how to deal with this.

Thanks

  • Hi Peng,
     
    USBx_DRVVBUS and USBx_VBUS are hardware related to each other. In Host mode the USB PHY drives DRVVBUS high, and then expects a valid VBUS voltage on VBUS input. What happens on your board is that VBUS probably jumps during ESD discharge, the PHY detects an error conditons on VBUS and swithches off DRVVBUS. This is done by hardware in the USB PHY and cannot be controlled by software.
  • Hi, Biser,

    I tried to disable the VBUS detection by cleaning usb_ctrl0 register otgvdet_en bit, but it didn't help. I'm wondering if there is some other method to disable this VBUS detection.

    If the DRVVBUS is automatically turned off, then how to turn on it again. Do I need to reset the totoal USB controller and re-initialize the port?

    Thanks,

     

     

  • There is no way to disable the VBUS detection. I'm no expert on software, but I think the port has to be re-initialized on VBUS error.
  • I don't know if the AM335X USB port has one protection option--When it detects the abnormal event on the VBUS, it switches off the DRVVBUS, when VBUS is low, it will re-assert DRVVBUS automatically.

    Perhaps I need to use the IRQ USB_8 to detect the DRVVBUS change and then software re-initialize the USB port.

     

  • Hi

    This is due to VBUS error condition would have occured when you have connected the device. The device could be drawing more current could lead to over-current condition, and controller will see it as vbus error. when this condition occur, controller shutdown (remove the session) and controller is no more in host mode and drvvbus will go Low to disable the VBUS charge pump. Some over-current device will work fine when the session set again by SW. The workaround solution will set the session again on vbus error interrupt, this causes the controller enter into host mode and set drvvbus to high. It seems in your case this vbus error occuring repeatedly and leads to endless loop. you can revert this workaround.

    Regards

    Ravi B

  • Hi, Ravi,

    When I set DEVCTL(SESSION) bit, the USB bus really resumes.

    We want S/W application be notified when DRVVBUS swiches to Low. However we found that S/W can only receive the IRQ--USB_8 R/W 0h Interrupt status for DRVVBUS level change--when DRVVBUS changes from 0 to 1, can't receive IRQ when DRVVBUS changes from 1 to 0. Is there some other special setting for this?

    Thanks,

    Peng

     

     

  • Hi, Ravi,

    I noticed S/W should use USB0IRQENABLECLR1 to enable IRQ when DRVVBUS changed from 1 to 0.

    Today I found that to set DEVCTL(SESSION) bit works well when single USB device connected to the port such as one USB stick, one keyboard or one barcode reader. However, when one Hub is connected, set DEVCTL(SESSION) bit  doesn't work and often cause the system to hang. I saw in the "Device Control Register (DEVCTL)" description in the SPRUER7E, it says "A special software routine is required to perform SRP. Details will be made available in a later document version." But I could not find a later version.Do you know where to find the reference about how to take care of this special software routine to perform SRP.

    Thanks,

    Peng

  •  

    USB0IRQENABLECLR1 is used to clear the IRQ enable, not set the falling-edge IRQ.