• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 104 subscribers
  • Views 12942 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

USB1 power control with DRVVBUS

Alfredo Agudo
Prodigy 50 points
Other Parts Discussed in Thread: TPS2051, AM3352

Hello, 

I am using a custom board with AM335x (mostly cloned from BeagleBone). We use USB1 host, with a UVC-compatible USB camera always plugged.

USB1_ID is grounded, USB1_DRVVBUS connected to TPS2051 (power switch) enable signal, USB1_VBUS connected to the TPS2051 output  and to the pin1 of USB A connector (usb power 5V). 

The camera works fine, but we want to control (switch-on and switch-off) the USB power (for power saving). And I don't know I to do it. 

We have found two problems:

  1. the USB1_DRVVBUS is controlled from the linux driver (and I don't found any way to instruct the driver to move it). 
  2. if I unplug and plug again the camera, the system disconnect and found the camera, but there is same dmesg errors: "[ 2037.444946] 6:3:1: cannot set freq 16000 to ep 0x86".... and when I try to use the camera another error: "uvcvideo: Failed to set UVC probe control : -110 (exp. 26)."

I can solve the second problem doing "rmmod uvcvideo" before pluging the camera. But probably there is a better solution!!

And about the first problem, I don't have a good solution. What could I do to control USB_DRVVBUS1? (from command line, from programm, from kernel...).

I have try to change USB1_DRVVBUS pin mux to 7 (gpio) and control it manually. It removes the power from USB but there is a lot of dmesg errors (every 250ms) "hub 1-0:1.0: over-current condition on port 1".

I have try to change USB1 mode to manually device (USB1MODE=0x180), trying to override the ID pin, and hopping that this would turn-off the DRVVBUS, but it didn´t work (probably only works on boot?). 

I could change the hardware layout in order to cheat  the driver: with a transistor I can send 5V to USB1_VBUS when the USB1_DRVVBUS is active; an I can use any other gpio to control from my program the TPS2051 switch to send power to the USB connector. I don´t know if this would work, but there should be a simpler software solution. 

Any idea? Thanks in advance, 

Alfredo Agudo

uname -a
Linux ibernexNX050x 3.2.42 #19 Mon Jun 3 19:06:27 CEST 2013 armv7l GNU/Linux

lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 046d:0825 Logitech, Inc.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

  • 0
    TI__Guru** 124546 points

    Alfredo Agudo said:
    the USB1_DRVVBUS is controlled from the linux driver (and I don't found any way to instruct the driver to move it). 

    If you look at the MUSB linux driver (drivers/usb/musb/musb_regs.h), you will find a 8-bit register called MUSB_DEVCTL, its bit0 MUSB_DEVCTL_SESSION controls USBx_DRVVBUS.

    The physical address of MUSB_DEVCTL for MUSB1 is 0x47401C60, you can use devmem2 tool to play with it.

    The MUSB driver in TI provided AM335x kernel already has a user-space interface in procfs (drivers/usb/musb/musb_procfs.c) to set the SESSION bit to turn on USBx_DRVVBUS, which is command 'echo F > /proc/driver/musb_hdrc.1' for MUSB1, you can use it as a reference to implement a new procfs interface to clear the SESSION bit to turn off USBx_DRVVBUS, if want your application to control the USB power.

    Alfredo Agudo said:
    if I unplug and plug again the camera, the system disconnect and found the camera, but there is same dmesg errors: "[ 2037.444946] 6:3:1: cannot set freq 16000 to ep 0x86".... and when I try to use the camera another error: "uvcvideo: Failed to set UVC probe control : -110 (exp. 26)."

    I do have a Logitech uvc webcam which has the 'cannot set freq...' error, even with my Linux PC (ubuntu 12.04), but it seems have no issue to use.

    The '-110' enumeration error needs further debug. Have you tried other uvc cams? Do you use kernel from TI.com? what is the psp/sdk version?

    Alfredo Agudo said:
    I have try to change USB1_DRVVBUS pin mux to 7 (gpio) and control it manually.

    This pinmux should not be changed in runtime.

    Alfredo Agudo said:
    I have try to change USB1 mode to manually device (USB1MODE=0x180), trying to override the ID pin, and hopping that this would turn-off the DRVVBUS, but it didn´t work (probably only works on boot?). 

    This change only take effect after clear then set the DEVCTL SESSION bit.

  • 0 in reply to Bin Liu
    Prodigy 50 points

    Thank you!

    It works perfectly: Modifying bit 0 of 8 bit register address 0x47401C60 it switch on/off USB1_DRVVBUS pin, without dmesg errors. 

    About the second problem ( "uvcvideo: Failed to set UVC probe control : -110 (exp. 26)" )  I am using Logitech C270 (but I still don´t know which will be the final model) and the Linux 3.2.41  from Angstrom.

    I don´t know the source of the second problem, but  I have found a solution: in order to revive the camera after the USB power on, instead of doing "rmmod uvcvideo; modprobe uvcvideo" I just call "v4l2-ctl --list-devices" or "v4l2-ctl -V" and then I can use the camera without problem. 

    Best Regards, 

    Alfredo Agudo

  • 0 in reply to Bin Liu
    Genius 5250 points

    Hi Bin,

    I am unable control usb power with DRVVBUS at runtime, I was using above procfs command i.e  echo F > /proc/driver/musb_hdrc.1 which showing below log message 

    root@am335x-evm:~# echo F > /proc/driver/musb_hdrc.1
    -sh: /proc/driver/musb_hdrc.1: No such file or directory

    could you tell me how to turn off and turn on USBx_DRVVBUS.

    Thanks & Regards 

    srinivas 

  • 0 in reply to Srini
    TI__Guru** 124546 points

    Srinivas,

    Which SDK do you use?

    'echo F ...' is only applicable to SDK6.0 or older. It does not exist since SDK7.0.

  • 0 in reply to Bin Liu
    Genius 5250 points

    Hi Bin liu,


    We are using sdk 8.0(kernel 3.14) 
    In our custom board(host mode) we are trying to disable USB charging for slave devices. 

    But we are facing an over-current issue with our board. USB controller on AM3352 processor is detecting over-current event which means the Mobile phone is trying to source more current from our board, which the board is not able to feed in. This is because of current being limited to 150mA for USB on the board. We have tried on multiple mobile phones (Samsung S4, Moto G, Sony, etc) and seeing the same issue on all of them.


    we do not want charging of phones using our board !

    could you tell me how disable usb controller. 

    Kindly do the needful as early as possible

    Many Thanks in advance,

  • 0 in reply to Srini
    TI__Guru** 124546 points

    I am not sure what is your reason of limiting the VBUS current to 150mA, but this violates the USB2.0 Spec. The USB2.0 host should provided minimum 500mA.

    Another issue is that even if you could disable the USB controller in your use case, then what is the point to connect the phone to your board via USB?

  • 0 in reply to Bin Liu
    Genius 5250 points
    Sorry bin Liu,

    Its not disabling the usb controller, actually our usb switch current limit is 150mA and our board usb otg is a power supplier, and an usb otg device is a power consumer(like mobile phones),

    Could you please help me how to stop charging devices from the USB otg port because Mobile USB devices require more power than it is permitted by the specifications for a single port.
  • 0 in reply to Srini
    TI__Guru** 124546 points

    Srini said:
    actually our usb switch current limit is 150mA

    As I said before, this design violates the USB2.0 Specs.

    Srini said:
    how to stop charging devices from the USB otg port

    I don't think there is any way to achieve this.

    Srini said:
    because Mobile USB devices require more power than it is permitted by the specifications for a single port.

    How much is the current? If it is not more than 500mA from the AM335x USB port, the mobile device still complies with the USB Spec.

  • 0 in reply to Bin Liu
    TI__Guru 55265 points
    The USB OTG specification says an OTG device that sources more than 100ma on VBUS is required to follow the power delivery requirements defined in the USB 2.0 specification. The USB 2.0 specification requires a standard host to source 500ma minimum. Therefore, your product should be able to source 500ma.

    The USB 2.0 specification also says a peripheral shall never consume more than 100ma before enumerating and asking permission to consume more power.

    Your product operating as host may not be compliant to the specification, but it should work when connected directly connected to a compliant peripheral. Your product is able to source 150ma, the compliant peripheral should only consume up to 100ma while negotiating with the driver for higher power, the driver should not give permission if the peripheral requests more than 150ma. In this case, the driver should disconnect the peripheral or continue to operate with reduced functionality at the lower power level. If the peripheral ignores the driver and begins to draw more power than your product can source, the VBUS source will current limit and indicate an over-current condition.

    Your product would never be able to support inserting a bus powered USB hub in downstream path as the hub may require up to 100ma and there would only be 50ma remaining for any peripheral.

    You may be able to get limited functionality if you could modify the mobile phone driver such that it would never give the mobile phone permission to consume more than 150ma.

    Regards,
    Paul
  • 0 in reply to peaves
    Intellectual 885 points

    Hi paul & Bin,

     Thanks for yours response,

    Problem: over current detection.

    I am using sdk 8.0 and kernel 3.14, In usb otg when I plugin any device to board after that  the USB OTG controller begins a host session the DRVVBUS output is driven high to enable a VBUS power switch.  The OTG controller is monitoring the VBUS voltage after a host session.

    how to determine if there is an over-current condition on VBUS line in driver level.

    Please find the below details.

    Usb power switch max current is150mA

    processor:am3352

    Schematic: BBB reff

    Thanks

    N Shankar.

  • 0 in reply to shankar naragoni
    TI__Guru 55265 points
    The host monitors voltage on VBUS to determine if it drops below the VBUS Valid level of 4.4 volts. If your product can only source 150mA and a peripheral consumes more than 150mA, your VBUS power source would limit current being sourced to VBUS which would cause the voltage to drop below VBUS Valid. When this happens an over-current interrupt will be generated and the host driver will turn off the port. You need to make sure the peripheral you connect to your product never consumes more than 150mA if you do not want an over-current condition.

    There is no way to no way to prevent an over-current condition if the peripheral you attach draws more current than you can source.

    Any peripheral that consumes more than 100mA of power from VBUS without asking permission from the host is non-compliant to the USB specification.

    You should not have a problem with a USB compliant peripheral.

    Regards,
    Paul
  • 0 in reply to peaves
    TI__Mastermind 27720 points

    More background on USB power can be found here:
    nttup.wordpress.com/.../usb-device-charging-un-mystified

  • 0 in reply to peaves
    Intellectual 885 points

    Thanks paul,

         Could you explain about USBx_OCn over current interrupt  pin for usb0 port, how it works and its registers and where can I find in usb driver source code.

    Thanks

    N Shankar   

  • 0 in reply to shankar naragoni
    Intellectual 885 points

    Hi Paul,

    I want to know about the overcurrent handling mechanism in linux USB driver of  AM335x.I am Using SDK8.0, linux-3.14.  how exactly it is done based on hardware pin notification and how usb driver knows over current detection on GPIO pin. I want to know GPIO pin on the SoC for overcurrent notifications from the USB power switch.In my custom board USB0_OC pin interfacing to GPIO0_2. Could you please give me details about OC pin.

     

    Thanks

    N shankar. 

  • 0 in reply to shankar naragoni
    TI__Guru 55265 points

    The USB PHY in AM335x monitors the voltage applied to the VBUS terminal to detect an over-current condition.  The USB host controller assumes the attached peripheral is consuming more current than the current-limited power switch is able to source if the voltage on the VBUS terminal drops below 4.4 volts while the DRVVBUS terminal is high.  When this occurs, the USB host controller generates an interrupt to the processor and the interrupt service routine in the driver should reading the various status registers to determine what generated the interrupt.  Once the driver determines there is an over-current condition, it should shut-off the port.

    I provide hardware support and do not know the details of software operation.

    Regards,
    Paul 

  • 0 in reply to peaves
    Intellectual 885 points

    Thanks Paul,

         The USB external interface signals are USB0_DRVBUS, USB0_VBUS ,USB0_CE,USB0_ID and data pins, usb external power switch having one over current detection flag(i.e USB0_OC ) and please let me know  which signal acts as over current detection interrupt.

    As per spruh data sheet Vbus error:

    The USB controller determining its role as a host, it will drive the USBx_DRVVBUS pin high to enable the external power logic so that it start sourcing the required 5V power (must be ≥ 4.4V but to account for the voltage drop on the cable it is suggested to be in the neighborhood of 4.75V). The USB2.0 controller will then wait to for the voltage of the USBx_VBUSIN to go high. After 100 ms, if it does not see the voltage on the USBX_VBUSIN pin to be within a Vbus Valid range (>= 4.4V), it will generate a Vbus error interrupt.

    Thanks

    N Shankar.