• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 1241 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.

AM3352: How to use USB1_DRVVBUS as gpio?

yingjie gu
Intellectual 810 points
Part Number: AM3352

Hi, 

The USB1_DRVVBUS pin is used as gpio3[13] in the hardware to control power supply control. I tried to control it from user mode.  Can anyone help to figure out what am I doing wrong? Thanks. 

I edited my kernel dts file as following:

&am33xx_pinmux {
        usb1_pins: pinmux_usb1_pins {
                pinctrl-single,pins = <
                        AM33XX_IOPAD(0xA34, PIN_OUTPUT_PULLDOWN | MUX_MODE7)      /* usb1_drvvbus.gpio3_13 */
                >;
        };
}
&gpio3 {
        status = "okay";
        ti,no-reset-on-init;
};
&usb1_phy {
        pinctrl-names = "default";
        pinctrl-0 = <&usb1_pins>;
        status = "okay";
        #phy-cells = <0>;
};
In user mode, I did 
$ echo out > gpio109/direction.
$ echo 1 > gpio109/value
I can detect that voltages changed when gpio value changed.
But no matter what, usb drive connected to USB1 is not recognized. 
Does using USB1_DRVVBUS as gpio disable usb1 host function some how? 
  • 0
    TI__Guru**** 167581 points

    Hi,

    You shouldn't use USBx_DRVVBUS pin in GPIO mode to control VBUS power. Its GPIO mode only means the pin is not used for USB function (for example, USB function is not needed or only peripheral mode is needed). This pin has to be in DRVVBUS mode if the USB module is used in host-only or dual-role mode.

  • 0 in reply to Bin Liu
    Prodigy 100 points

    I was wondering if I could get further clarification on the operation of the USB_DRVVBUS pin in conjunction with the overall USB sub-system. The TRM is unclear on some of the interrelationships. For example, if the USB host is experiencing an overcurrent condition, how is that manifested in terms of the operation of the USB controller, and specifically to the operation of the USB-DRVVBUS pin? What I would like to see happen is the pin control for the USB Host 5V power module should shut down the module for a period of time, before trying to bring it up again. If it experiences another overcurrent event within a short time period, it should shut down the module (and USB host controller?) again, and perhaps declare a hardware fault and leave it shut down. Also, the TRM says the DRVVBUS signal will go active, then the controller waits up to 100ms for the VBUS_IN to go active. If the situation is that the USB Host 5V power module takes longer than 100ms to power up (it shouldn't but I want to explore contingencies), is there a way to delay or otherwise adjust this behaviour?

    I look forward to your reply.

  • 0 in reply to Brian Carrigan
    TI__Guru**** 167581 points

    Hi Brian,

    USBx_DRVVBUS is an output pin to control the VBUS power switch. Typically when the MUSB controller transitions to host mode (based on the condition of VBUS_VALID and/or ID pin status), the controller asserts USBx_DRVVBUS pin. When the MUSB controller transition to peripheral mode (again, based on the condition of VBUS_VALID and/or ID pin status), the controller de-asserts USBx_DRVVBUS pin.

    In case of overcurrent condition, MUSB controller itself doesn't detect VBUS current, but if the overcurrent condition causes VBUS drop below VBUS_VALID threshold, MUSB controller will transition from host to peripheral mode and de-assert USBx_DRVVBUS. MUSB controller itself doesn't recover from the overcurrent condition, software has to initiate the peripheral mode to host mode transition. Currently in Linux the USB core driver will try to re-initiate 3 times. If all failed due to the overcurrent condition, the host port is shut down until reboot or reload the USB drivers.

    Brian Carrigan said:
    Also, the TRM says the DRVVBUS signal will go active, then the controller waits up to 100ms for the VBUS_IN to go active. If the situation is that the USB Host 5V power module takes longer than 100ms to power up (it shouldn't but I want to explore contingencies),

    If the VBUS takes more than 100 ms to reach VBUS_VALID threshold, MUSB controller will not transition to host mode.

    Brian Carrigan said:
    is there a way to delay or otherwise adjust this behaviour?

    No, the 100ms timeout is hardcoded in the controller.

  • 0 in reply to Bin Liu
    Prodigy 100 points

    Thank you for your response. I think that may clarify things for me.

  • 0 in reply to Bin Liu
    Intellectual 810 points

    Hi Bin,

    Can you provide some reference document or posts on how to switch MUSB between host and device by software in user mode?  Thanks.

  • 0 in reply to yingjie gu
    TI__Guru**** 167581 points

    Hi Yingjie,

    You cannot directly switch MUSB between host and device mode with Linux user space software. If so, one could easily create a scenario which violates the USB Specifications.

    The MUSB mode switching relies on the USB cable connection to the micro-AB receptacle.

    When connecting MUSB to a USB host, you plug in a micro-B cable to MUSB. MUSB detects VBUS presence and its ID pin is floating, to go device mode.

    When connecting MUSB to a USB device, you plug in a micro-A cable to MUSB. MUSB detects its ID pin is grounded, then asserts USBx_DRVVBUS pin to provide VBUS to the USB device and MUSB switches to host mode.

  • 0 in reply to Bin Liu
    Intellectual 810 points

    Hi Bin,

    I found this status after I boot up the system:

     #cat /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/mode
    a_wait_bcon
    # cat /sys/firmware/devicetree/base/ocp/usb\@47400000/usb\@47401800/dr_mode 
    host
    What does the a_wait_bcon mean? If I connect a usb device to USB1, the status doesn't change, and usb device is not detected.
  • 0 in reply to yingjie gu
    TI__Guru**** 167581 points

    Hi Yingjie,

    a_wait_bcon is a state in the OTG State Machine defined in the USB OTG Spec. You can think of it as USB host waiting for USB device to connect.

    To understand why the USB device is not detected, please

    - Is this on your customer board or TI EVM? If former please provide the USB portion of the schematics, including all the signal connections between AM335x MUSB to the USB receptacle;

    - What version of the SDK do you use?

    - provide the register dump before and after plugged in the USB device using the following command:

    # grep -i 'devctl\|power' /sys/kernel/debug/musb-hdrc.1/regdump

  • 0 in reply to Bin Liu
    Intellectual 810 points

    Hi Bin,

    My SDK is 5.0.0.15.

    We are using customized board. 

    Here is the schematics.

    dmt303c-usb.pdf

    # grep -i 'devctl\|power' /sys/kernel/debug/musb-hdrc.1/regdump

    Power : e0
    DevCtl : 19

  • 0 in reply to yingjie gu
    TI__Guru**** 167581 points

    Hi Yingjie,

    The register dump shows the MUSB controller is ready and waiting for device attach. I don't see any obverse problem in your board AM335x USB1 design. I noticed you have a hub on the board connected to AM335x USB1, but the hub is not enumerated on USB1. Please check the hub data sheet to ensure the design around the hub is all correct. Please also measure USB1_DP pin if it goes high after AM335x is powered on.

    By the USB Spec, the hub upstream port should turn on DP or DM pullup only when VBUS is valid. In your hub design, how does the hub know when it should turn on its pullup?