• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 5 answers
  • Subscribers 99 subscribers
  • Views 4299 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.

PROCESSOR-SDK-AM335X: USB1 Host mode issue

Michael Amoruso
Intellectual 275 points
Part Number: PROCESSOR-SDK-AM335X

I have devices hooked up to USB0 and USB1 on a custom design. I am able to boot into linux, and I make USB1 a host, which is connected to a USB to Eth LAN9500A chip. The processor, however, is not able to see anything on USB1. I can show you snippets of the schematic where there are issues and maybe you can help out?

  • 0
    Intellectual 275 points
    As a side note, I am able to fully use the device on USB0. In the Uboot we make USB0 a host and USB1 a peripheral. I load code from USB0 into the eMMC in order to boot into linux. Once in linux, we are able to make USB1 a host as well, however, still not able to see the device on USB1.
  • 0
    TI__Guru**** 393215 points
    Hi,

    You need a separate VBUS switch for USB1, which should be controlled by USB1_DRVVBUS.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 275 points
    That makes sense for separate functionality. However, I am just wondering if we are able to see USB0, and that enable on USB0 technically drives the power for USB0 and USB1, why exactly will it still not see USB1 in this situation as long as USB0 is being enabled?
  • 0 in reply to Michael Amoruso
    TI__Guru**** 169071 points

    Michael,

    Ideally the design requires to separate the VBUS lines of USB0 and USB1. In your design, If USB0 has already enabled VBUS power switch, then later when USB1 wants to transition to host mode it will fail, due to VBUS already has >= 4.4v voltage.

    If you use v4.1 or v4.4 kernel, you could apply the following two patches to workaround the problem.

    [PATCH RESEND v2 1/2] usb: phy: correct the am335x phy header filename

    [PATCH v3] usb: phy: phy-am335x: bypass first VBUS sensing for host-only mode

  • 0 in reply to Bin Liu
    TI__Guru**** 169071 points
    With those two patches applied, you need to set dr_mode="host" in your dts file.
  • 0 in reply to Bin Liu
    Intellectual 275 points
    We have tried to patch this however still not able to get USB1 to initialize. Is there something we may have missed?
  • 0 in reply to Michael Amoruso
    TI__Guru**** 169071 points

    After USB0 turned on VBUS power switch, do run the following command to turn on USB1, then test again.

    # devmem2 0x47401c60 b 1

    If still doesn't work, run the following command to get two register dumps.

    # devmem2 0x47401c01 b
    # devmem2 0x47401c60 b

  • 0 in reply to Bin Liu
    Prodigy 90 points

    This is what we get.  The devices on Bus 01 are still invisible:


    root@arm:~# ./devmem2 0x47401c60 b 1
    /dev/mem opened.
    Memory mapped at address 0xb6f2f000.
    Value at address 0x47401C60 (0xb6f2fc60): 0x19
    Written 0x1; readback 0x19
    root@arm:~# lsusb -t
    /:  Bus 02.Port 1: Dev 1, class="root_hub", Driver=musb-hdrc/1p, 480M
    /:  Bus 01.Port 1: Dev 1, class="root_hub", Driver=musb-hdrc/1p, 480M
        |__ Port 1: Dev 2, If 0, class="Mass" Storage, Driver=usb-storage, 480M
    root@arm:~# ./devmem2 0x47401c01 b
    /dev/mem opened.
    Memory mapped at address 0xb6f84000.
    Value at address 0x47401C01 (0xb6f84c01): 0xE0
    root@arm:~# ./devmem2 0x47401c60 b
    /dev/mem opened.
    Memory mapped at address 0xb6f7c000.
    Value at address 0x47401C60 (0xb6f7cc60): 0x19

    The kernel (4.4.32) already has the latest patches.

  • 0 in reply to Vladimir Boroda
    TI__Guru**** 169071 points
    The registers show the MUSB1 is already in the correct state. But It is possible the high-speed usb device is not enabling DP pullup, so the bus is unable to detect it.

    Does the USB1 receptacle has 5V VBUS_FIL signal? Please probe if USB1 header has 5V on VBUS pin. If so, then please probe if DP has pullup when a high-speed usb device is attached.
  • 0 in reply to Bin Liu
    Intellectual 275 points
    The device attached the the USB1 is a LAN9500A USB to ETH chip. There is 5V on USB1_VBUS, however DP does not have any voltage on it. I did probe all the voltages on the LAN9500A device and they are present.
  • 0 in reply to Michael Amoruso
    TI__Mastermind 27890 points
    The ETH chip needs to see VBUS before it will activate its pull-up on DP. We won't know it's there until we see said pull-up, after which we will begin USB enumeration.

    Sounds like the ETH chip isn't seeing VBUS or is possibly suspended/in reset.
  • 0 in reply to Michael Amoruso
    TI__Guru**** 169071 points

    Michael Amoruso said:
    The device attached the the USB1 is a LAN9500A USB to ETH chip. There is 5V on USB1_VBUS, however DP does not have any voltage on it. I did probe all the voltages on the LAN9500A device and they are present.

    It sounds like the USB-ETH chip is not a dongle attached through the standard type-A receptacle, but permanently soldered on the board, is it the case?

  • 0 in reply to Bin Liu
    Intellectual 275 points

    Yes, this is the case. It is an IC on the PCB. In a previous design we connected a USB Hub IC to USB1 and connected this exact LAN9500A chip to a USB interface on the HUB and that worked. Now we have the same design, except we do not use the USB Hub we simply use the USB1 interface on the processor to make the connection to the LAN9500A.

  • 0 in reply to Michael Amoruso
    TI__Guru**** 169071 points

    Michael Amoruso said:
    Yes, this is the case. It is an IC on the PCB.

    Ok, it seems like there is problems in hooking up the USB-ETH chip as well. If your design is correct, the ETH chip should enable the DP pullup once received 5V VBUS, then the USB host can detect the attach and start the enumeration.

  • 0 in reply to Bin Liu
    Prodigy 90 points

    Really strange behavior from the USB driver (after I enabled the GPIO0_6 as USB1 PHY reset).  It's not that it doesn't see the LAN9500A device at all, but it doesn't seem to be able to communicate with it:

    [    2.662428] usb 2-1: device descriptor read/64, error -71
    [    2.892508] usb 2-1: device descriptor read/64, error -71
    [    3.122493] usb 2-1: new low-speed USB device number 3 using musb-hdrc
    [    3.272535] usb 2-1: device descriptor read/64, error -71
    [    3.523462] usb 2-1: device descriptor read/64, error -71
    [    3.752541] usb 2-1: new low-speed USB device number 4 using musb-hdrc
    [    4.183409] usb 2-1: device not accepting address 4, error -71
    [    4.313393] usb 2-1: new low-speed USB device number 5 using musb-hdrc
    [    4.742382] usb 2-1: device not accepting address 5, error -71
    [    4.748331] usb usb2-port1: unable to enumerate USB device

  • 0 in reply to Vladimir Boroda
    TI__Guru**** 169071 points
    Typically this kind of error log means the connect timing problem of the 4 wires of the USB bus, especially with a device IC permanently on the PCB, (of cause, many other problems also cause this error log too.)

    However, I don't recall the MUSB PHY requires a GPIO for reset, why and how do you use GPIO0_6?
  • 0 in reply to Bin Liu
    Intellectual 275 points

    On the old design we had the reset on the LAN9500A tied to the PRTCTL line of the USB Hub which does the following: When used as an output, this pin enables power to downstream USB peripheral 5. Since we got rid of the USB Hub, we tied this to a gpio to be able to have control of it. The reset on the LAN9500A is active low, and someone had made a comment that this part might be held in reset, so we drive this High to take the LAN9500A device out of reset.

  • 0 in reply to Michael Amoruso
    TI__Guru**** 169071 points
    Ok, the GPIO0_6 is not for USB1 PHY reset, but for LAN9500A. I am afraid that I am unable to help much from here since I don't know this chip. You might want to consult the issue with LAN9500A vendor.
  • 0 in reply to Bin Liu
    Prodigy 90 points
    We have the LAN9500_RSTn hooked up to the GPIO0_6. When I left it unconfigured (tristated), the driver didn't sense any devices at all on the USB2. When configured as 'reset-gpios' property of node /ocp/usb@47400000/usb-phy@47401b00[0], seemed to cause at least some action (obviously, not what we desire from it). I will remove it as it doesn't seem to work.
  • 0 in reply to Vladimir Boroda
    TI__Guru**** 169071 points
    You might want to get help from the LAN9500A vendor.

    But I have a few pointers to the musb host to help solving the issue.

    - You might want to add 'usbcore.autosuspend=-1' in the uboot bootargs to disable usb autosuspend to simplify the usb bus activity;

    - You can decouple am335x usb0 and usb1 by separating USB0_VBUS and USB1_VBUS pins (I never saw am335x MUSB is designed this way before...). Keep USB0_VBUS with the current power switch, but directly connect USB1_VBUS pin to a 5V power rail. You still need the two patches I mentioned previously, and set USB1 dr_mode="host" in dts.

    - After kernel booted, check register "devmem2 0x47401c60 b', if it is 0x19, it means USB1 is ready to detect any attach; if it is 0x3D, it means a full/low-speed device is detected (which shouldn't be in your case); if it is 0x5D, it means a high-speed device is detected. I think any other value means USB1 is not in an expected state, let me know if it does happen.