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.

Linux/PROCESSOR-SDK-AM335X: Hardware conflict in USB OTG mode

Part Number: PROCESSOR-SDK-AM335X
Other Parts Discussed in Thread: AM3359, TPS65217

Tool/software: Linux

Hi,

I am developing am3359 board based on BeagleBone White and am3359evm schematic
(am3359 + tps65217 + NAND + USB0 OTG).

I tested the board under TI SDK 05.01.00.11 (kernel 4.14.67-gd315a9bb00).
Bootloader detects my board as BeagleBone White and boot am335x-bone.dtb file.
USB0 works fine in peripheral OTG mode.
But I need full OTG mode (peripheral and host).

Therefore I defined USB0 OTG mode in arch/arm/boot/dts/am335x-bone.dts:
&usb0 {
    dr_mode = "otg";
};
and compiled it.

For host mode I used cable-adapter like this:
www.amazon.com/.../B00VWTD7CQ

Any device is detected and properly works when I connect it though the adapter.
When I disconnect device together adapter also all is Ok.
But when I disconnect device from adapter, and then I disconnect empty adapter from the board,
then 5 Volts power stay active on mini-USB connector.

If next I try to use peripheral mode (connect the board to my laptop), then I have powering hardware conlict.
As result on-board 5 Volt DC-DC begin to overheat.

What I need change in dts settings or kernel config to fix this problem?

Regards,
Oleg.

  • Hi Oleg,

    I am able to replicate the issue on am335x evm. I will debug it and provide you the fix.
  • Hi Bin,

    Did you reproduce the bug on am335x evm?
    Do you need some additional information from me?

    Regards,
    Oleg.
  • Hi Oleg,

    Yes, I am able to reproduce the issue.

    I will schedule the work to fix the problem. For now please ensure to always attach the usb cable-adapter with a usb device and detach the adapter with the usb device together to avoid the issue, until I provide the kernel patch to fix the issue.
  • Hi Bin,

    Thank you for response.
    Of course, I will follow your recommendation and wait patch.

    Regards,
    Oleg.
  • Hi Oleg,

    Please apply the kernel patch below and let me know if it solves the problem.

    From 08649a65dfbe86afa2c7549ef97ed20cc559e6fc Mon Sep 17 00:00:00 2001
    From: Bin Liu <b-liu@ti.com>
    Date: Tue, 27 Nov 2018 14:36:49 -0600
    Subject: [PATCH] usb: musb: dsps: fix otg state machine
    
    Due to lack of ID pin interrupt event on AM335x devices, the musb dsps
    driver uses polling to detect usb device attach for dual-role port.
    
    But in the case if a micro-A cable adapter is attached without a USB device
    attached to the cable, the musb state machine gets stuck in a_wait_vrise
    state waiting for the MUSB_CONNECT interrupt which won't happen due to the
    usb device is not attached. The state is stuck in a_wait_vrise even after
    the micro-A cable is detached, which could cause VBUS retention if then the
    dual-role port is attached to a host port.
    
    To fix the problem, make a_wait_vrise as a transient state, then move the
    state to either a_wait_bcon for host port or a_idle state for dual-role
    port, if no usb device is attached to the port.
    
    Signed-off-by: Bin Liu <b-liu@ti.com>
    ---
     drivers/usb/musb/musb_dsps.c | 9 +++++++--
     1 file changed, 7 insertions(+), 2 deletions(-)
    
    diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
    index dbb482b7e0ba..0c50f38ae4ef 100644
    --- a/drivers/usb/musb/musb_dsps.c
    +++ b/drivers/usb/musb/musb_dsps.c
    @@ -242,8 +242,13 @@ static int dsps_check_status(struct musb *musb, void *unused)
     
     	switch (musb->xceiv->otg->state) {
     	case OTG_STATE_A_WAIT_VRISE:
    -		dsps_mod_timer_optional(glue);
    -		break;
    +		if (musb->port_mode == MUSB_PORT_MODE_HOST) {
    +			musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON;
    +			dsps_mod_timer_optional(glue);
    +			break;
    +		}
    +		/* fall through */
    +
     	case OTG_STATE_A_WAIT_BCON:
     		/* keep VBUS on for host-only mode */
     		if (musb->port_mode == MUSB_PORT_MODE_HOST) {
    -- 
    2.17.1
    
    

  • Hi Bin,

    Thank you very much for patch.

    I had applied it and now hardware conflict is removed.

    But when only adapter is connected to OTG USB (without device), then DC-DC switches 5 Volts off/on periodically.

    Please see oscilloscope screenshot:

    I don't know is it Ok for 5 Volt DC-DC.

    But I hope nobody will not stay this mode for a long time.

    Regards,

    Oleg.

  • Oleg,

    Oleg Strelkov said:
    But when only adapter is connected to OTG USB (without device), then DC-DC switches 5 Volts off/on periodically.

    This is expected.

    When the musb port is in dual role mode (dr_mode = "peripheral" in dts), the usb port is in b_idle state by default in which the VBUS power is not supplied, then the USB port won't be able to detect USB device attach. So the Linux kernel driver uses a timer periodically to turn on VBUS power and transition the port to a_wait_vrise state so that the port can detect USB device attach.

    When the USB port is attached to a host port, it becomes b_peripheral state in the driver, the timer stops.

  • Thank you, Bin. I get you.
    Do you support only newest SDK, or more older too?
    This bug is present in kernels 3.12.10-ti2013.12.01, 4.4.41+gitAUTOINC+f9f6f0db2d-gf9f6f0db2d, 4.9.69+gitAUTOINC+9ce43c71ae-g9ce43c71ae,
    as I found
  • Oleg,

    Yes, I noticed the bug exists in 3.12.10-ti2013.12.01 which is the very first kernel supporting AM335x by TI. Basically the bug exists from day one as far as I realized it.
    But over times the musb drivers got changed from kernel version to version, so it is not straight forward to back port the fix patch to older kernels.

    The patch I posted above is for v4.9 and v4.14 trees.
    The patch for current mainline kernel (v4.20+) is slightly different, I have sent it to the kernel community for comments, it should get into the mainline kernel in v4.21 development window.
    The fix patch for v4.4 will be different. I don't plan to solve it until someone complain about this issue.
    Kernel v3.12 is no longer maintained in the kernel community, so definitely I won't fix the issue in v3.12 (there is no where to release/host the fix).

  • Ok, Bin, thank you very much for help.

    With kindly regards,
    Oleg.
  • Thanks you for reporting the bug.