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 USB1_OCn pin issue

Other Parts Discussed in Thread: AM3352, TPS2051, TPS2015

Hi Team,
I met one issue related with the AM3352 USB1_OCn pin. My customer is using the USB1 as the host mode.
The software they're using is the Starterware 02_00_01_01. The demo they're using the usb_device_host_msc project is under the directory C:\ti\AM335X_StarterWare_02_00_01_01\build\armv7a\cgt_ccs\am335x\beaglebone\usb_device_host_msc.


In their first hardware version, they took the BBB's EVM's design on the USB part as the reference exactly, they used the ZCZ T16 ball(GPIO1_26) as the USB1_OCn pin. It worked well with the USB function.

But in the second version, they removed the TPS2051, connected the VBUS to the 5V input of the board directly, finding the USB1 port could not work properly. Then we measured the USBDRVVBUS, it is low, but not high. According to the datasheet, USBDRVVBUS should be high when working correctly as the host.
We checked this issue very carefully with the first version hardware, if they removed the TPS2051, connecting the VBUS to the 5V system power. It worked well when the USB1_OCn is pulled high with 10K resistor to 3.3V, but failed if the USB1_OCn is left unconnected. The issue observation is similar with the second version board.


So my question is:
1. Is USB1_OCn is a must for the host function when using Starterware? As i checked the Starterware codes, I found nothing related with the USB1_OCn(GPIO1_26) function, I'm very curious about the USB1_OCn's function during a USB1 host usage, I would appreciate if anyone could give some comments on the details.

2. for the Starterware application, is it all right to use the system power 5V directly as the VBUS?

  • Hi Steven,

    typically to enter host mode, the controller will check to see if there is voltage on VBUS to assure there is no host supplying VBUS.  On the second revision of the board you mention, VBUS is already present when it is attempting to become host, so you would have to modify the code to skip this check.  My understanding is that there is a patch in linux to achieve this, but Starterware probably doesn't have this patch available.  You would need to modify Starterware code.  I try to see if i can find the patch.

    Regards,

    James

  • Steven,

    See the E2E thread https://e2e.ti.com/support/arm/sitara_arm/f/791/p/533061/1942140

    For testing purpose, you can connect VBUS of USB1 directly to +5V, customer found that worked properly (they used USB0). If USBDRVVBUS is however low in your case, it is problem. Please also check the thread for the function of USB1_OCn.

    Regards, Eric

  • Thanks James,
    I think the patch you mentioned should be this one:
    e2e.ti.com/.../1163908
    Replied by Bin.

    For the Starterware, I didn't see any patch. Do you have more information? Or the customers have to modify the Starterware codes themselves for the same operation?
  • Hi Eric,
    Thanks for you reply!
    I think the issue part is the USBDRVVBUS is low in my test case. This is somehow unreasonable.
    So I'm trying to ask for help on the clues, what could lead to the low of the USBDRVVBUS. The hardware is designed as the host, following the SCH checklist's requirement.
  • Steven, this is the patch in Linux which disables the VBUS detect.  Note this patch would only be necessary in your case in which 5V is directly connected to VBUS.

    http://e2e.ti.com/support/arm/sitara_arm/f/791/p/331883/1193892#1193892

    You would also have to remove the overcurrent check of the GPIO, since that is also not being driven by the external power switch.

    Once you make those 2 changes in software, the Starterware driver should be able to configure the USB controller in host mode.

    Regards,

    James

  • Steven,

    I looked at another package (Processor RTOS SDK 3.1, released in Oct 2016) for AM335x device, it also supports USB host mode and tested on AM335x GP EVM.  The schematic is given at http://www.ti.com/tool/TMDXEVM3358 : 

    Power switch TPS2015 is used and the USB1_OC is connected to H18 (GPIO0_29). I also didn't find any code in the package operating on this GPIO pin.

    The usbphyon function like this:

    void UsbPhyOn(uint32_t uiPHYConfigRegAddr)
    {
        uint32_t usbphycfg = 0;

        usbphycfg = HWREG(uiPHYConfigRegAddr);
        usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
        usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN);

        HWREG(uiPHYConfigRegAddr) = usbphycfg;
    }

    This function is called several times, this code doesn't clear USBPHY_OTGVDET_EN first, then re-enable it. So the Linux patch only appies in the case VBUS is directly connected to +5V power supply as James pointed out.

    From TPS 2051 manual  http://www.ti.com/lit/ds/symlink/tps2041.pdf  :

    overcurrent (OC) The OC open drain output is asserted (active low) when an overcurrent or overtemperature condition is encountered. The output will remain asserted until the overcurrent or overtemperature condition is removed.

    So you may need to measure the OC pin is HIGH or LOW in both connected (working) or disconnected (non-working) case, and if this related to VBUS HIGH or LOW in host mode. Then, you may need GPIO code to make OC is high (I don't understand in disconnected case, what is disconnected from what?).  

    Regards, Eric

  • Hi Eric,

     Many thanks for your reply!

     so according to your comments, if the USB_VBUS connected to the 5V directly, we only need to add below red codes will work. Is it right?

    void UsbPhyOn(uint32_t uiPHYConfigRegAddr)
    {
    uint32_t usbphycfg = 0;

    usbphycfg = HWREG(uiPHYConfigRegAddr);
    usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
    usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN);
    usbphycfg &= ~USBPHY_OTGVDET_EN;

    HWREG(uiPHYConfigRegAddr) = usbphycfg;
    }

    Echo to your last question, i would like to clarify that, in the customer's second design, there's no TPS2051 chip on the board, the VBUS is connected to the 5V power directly. The USB1_OCn pin I mentioned meant the GPIO pin in the AM3352 side, just like the pin GPIO0_29 refer to your example SCH. Customer did the test to pull the AM3352 related pin to high or low to test the USB function, this lead to different result on the USB1_DRVVBUS pin. If it is pulled high, the USB1_DRVVBUS is high, USB worked normally. If it is pulled down, the USB1_DRVVBUS is low, USB didn't work well. In both cases, USB1_VBUS is always connected to the 5V power.

    So I agree with James' comments, there might be some codes on this GPIO detection. However, I didn't find it. As you mentioned, there seems no codes related with the GPIO pin detection. So I'm confused here. This part might be an important factor lead to my customer's USB failure. 

    If you have any comments, feel free to let me know! Many thanks!

  • Hi James,
    Many thanks for your response!
    I'm trying to check the codes of the Starterware 02.00.01.01 for the GPIO detection. However, didn't find it today. I'll continue to try.
    If any comments or process from your side, feel free to let me know! Highly appreciate!
  • Steven,

    There are discussions from Bin "AM335x MUSB is a OTG dual-role USB controller, which transitions between host and peripheral mode ( A-device or B-device in OTG terms) depending on some conditions. Due to the nature of OTG logic, while transition to host mode, MUSB first senses USBx_VBUS to ensure VBUS does NOT have any voltage, (this is called the first VBUS sensing.) then starts the transition. Within 100ms, MUSB senses VBUS again to ensure VBUS has been raised to the valid threshold, (this is the seconds VBUS sensing.)

    In the case that USBx_VBUS is directly tied to 5V power rail, MUSB may work after the system boots up. The first VBUS sensing passed due to the boot-up timing. However, in normal USB host operation, there are conditions, such as VBUS ERROR or babble, which will cause MUSB transition to peripheral/B-device mode. If that happens, MUSB is no longer able to transition to host mode again, because the first VBUS sensing will fail due to USBx_VBUS tied to 5V. Clearing bit-19 makes MUSB bypass the first VBUS sensing, which fixes this issue."

    So the code change would like what you suggested for USB1 only (which has +5v directly connected for host mode), you need to some condition check of uiPHYConfigRegAddr to make sure not break USB0:

    void UsbPhyOn(uint32_t uiPHYConfigRegAddr)
    {
    uint32_t usbphycfg = 0;

    usbphycfg = HWREG(uiPHYConfigRegAddr);
    usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
    usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN);
    usbphycfg &= ~USBPHY_OTGVDET_EN;

    HWREG(uiPHYConfigRegAddr) = usbphycfg;
    }

    or:
    void UsbPhyOn(uint32_t uiPHYConfigRegAddr)
    {
    uint32_t usbphycfg = 0;

    usbphycfg = HWREG(uiPHYConfigRegAddr);
    usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN | USBPHY_OTGVDET_EN);
    usbphycfg |= USBPHY_OTGSESSEND_EN;

    HWREG(uiPHYConfigRegAddr) = usbphycfg;
    }

    "Customer did the test to pull the AM3352 related pin to high or low to test the USB function, this lead to different result on the USB1_DRVVBUS pin. If it is pulled high, the USB1_DRVVBUS is high, USB worked normally. If it is pulled down, the USB1_DRVVBUS is low, USB didn't work well. In both cases, USB1_VBUS is always connected to the 5V power."=====>if customer know which "related pin to high or low" and this pin is connected to GPIO, then customer can add GPIO code to make this GPIO to the output direction and high(?) to make USB1_DRVVBUS high. In our EVM deisgn, we have TPS power switch and I didn't find GPIO code.

    Regards, Eric
  • Hi Eric,
    Many thanks for your detailed explanation and pointing out the functions.
    My customer followed the suggestion and modified the codes as below. When we set USB_TEST as 1, it would execute the test1 codes as you pointed out. When the USB_TEST is set as 2, it executed the second way. When changing it to 0, it would work as the original way. However, all the tests didn't show a succeeded process as a USB host. It sill didn't work normally. What else can we do to analysis what happened here?
    As this is a very urgent case, I would appreciate for any comment! Many thanks!
    ------------------------------------------
    #define USB_TEST 1
    ------------------------------------------
    void UsbPhyOn(unsigned int ulIndex)
    {
    unsigned int usbphycfg = 0;
    #if defined (am335x_15x15) || defined(am335x) || defined(c6a811x)
    ASSERT((0==ulIndex)||(1==ulIndex));
    #else
    ASSERT(0==ulIndex);
    #endif /* defined (am335x_15x15) || ... */

    #ifdef USB_MODE_FULLSPEED
    if (0==ulIndex)
    HWREGB(USB0_BASE + USB_O_POWER) &= 0xdf;
    #if defined (am335x_15x15) || defined(am335x) || defined(c6a811x)
    else
    HWREGB(USB1_BASE + USB_O_POWER) &= 0xdf;
    #endif /* defined (am335x_15x15) || ... */
    #endif /* USB_MODE_HS_DISABLE */

    #if USB_TEST == 0 //original codes
    usbphycfg = HWREG(g_USBInstance[ulIndex].uiPHYConfigRegAddr);
    usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
    usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN);

    HWREG(g_USBInstance[ulIndex].uiPHYConfigRegAddr) = usbphycfg;

    #elif USB_TEST == 1 // test 1 codes
    usbphycfg = HWREG(g_USBInstance[ulIndex].uiPHYConfigRegAddr);
    usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
    usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN);
    usbphycfg &= ~USBPHY_OTGVDET_EN;

    HWREG(g_USBInstance[ulIndex].uiPHYConfigRegAddr) = usbphycfg;

    #else //test 2 codes
    usbphycfg = HWREG(g_USBInstance[ulIndex].uiPHYConfigRegAddr);
    usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN | USBPHY_OTGVDET_EN);
    usbphycfg |= USBPHY_OTGSESSEND_EN;

    HWREG(g_USBInstance[ulIndex].uiPHYConfigRegAddr) = usbphycfg;
    #endif
    }
  • Echo to your last question:
    "Customer did the test to pull the AM3352 related pin to high or low to test the USB function, this lead to different result on the USB1_DRVVBUS pin. If it is pulled high, the USB1_DRVVBUS is high, USB worked normally. If it is pulled down, the USB1_DRVVBUS is low, USB didn't work well. In both cases, USB1_VBUS is always connected to the 5V power."
    =====>if customer know which "related pin to high or low" and this pin is connected to GPIO, then customer can add GPIO code to make this GPIO to the output direction and high(?) to make USB1_DRVVBUS high. In our EVM deisgn, we have TPS power switch and I didn't find GPIO code.

    ==>Steven: I mentioned this just because this observation is very suspicious. I checked the code carefully, and didn't find GPIO code either. So, to some extent, I agree that the root cause is not the GPIO toggling related, but VUBS sensing. But not sure as the issue is not solved by changing the code.
    BTW, the GPIO I mentioned is follow StarterKit EVM 's design. processors.wiki.ti.com/.../TMDSSK3358_3H0009_REV1_2B_SCH.pdf
    I also tried to set this GPIO's Pinmux to make it pull up and down. But this is not affecting the result.
  • Steven,

    As the power switch was removed from customer design, the following are needed to put the USB in host mode:
    1. Set the USB1_OCn high as in the case with power switch presented, the pin can't be float
    2. Disable the VBUS sensing in usbphyon() code which you already did. VBUS sensing is not related to this issue, but it is required in the case when VBUS is tied to 5V directly

    The thread mentioned following observations:
    1) removed the TPS2051, connecting the VBUS to the 5V system power. It worked well when the USB1_OCn is pulled high with 10K resistor to 3.3V"
    2) Customer did the test to pull the AM3352 related pin to high or low to test the USB function, this lead to different result on the USB1_DRVVBUS pin. If it is pulled high, the USB1_DRVVBUS is high, USB worked normally. If it is pulled down, the USB1_DRVVBUS is low, USB didn't work well. In both cases, USB1_VBUS is always connected to the 5V power.
    3) I mentioned this just because this observation is very suspicious. I checked the code carefully, and didn't find GPIO code either. So, to some extent, I agree that the root cause is not the GPIO toggling related, but VUBS sensing. But not sure as the issue is not solved by changing the code. ...I also tried to set this GPIO's Pinmux to make it pull up and down. But this is not affecting the result.

    The observations 1) and 2) match, what is the "related pin" in 2), it is unclear to me. But 3) seems conflict with 1) and 2). Given 3) is the latest, are 1) and 2) still hold?

    If 1) and 2) are still hold, can they use that as a solution?

    Regards, Eric