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.

AM4379: RNDIS USB device mode not working after hot swapping from USB host mode under OTG configuration

Part Number: AM4379
Other Parts Discussed in Thread: AM4378, TPD4S012

Tool/software:

Issue Title : RNDIS USB device mode does not work after being switched from USB host under USB0 OTG mode configuration 

SDK version : Linux-rt-am437x-evm-06.03.00.106

My H/W board with AM4378 uses single USB0 port for ethernet connection. And USB0 port is expected to support hot swapping between RNDIS ethernet over USB0 (device mode) and USB0 to ethernet adapter (host mode, Micro USB to RJ45). USB0 is configured as OTG mode in device tree. And the following scenarios (1,2,3) work well. However, test case 4 fails. Do you provide me with any idea for debugging this issue?

1. RNDIS USB device mode : Good

2. USB host mode for USB0 to ethernet adapter : Good

3. Hot swapping from RNDIS USB device mode to USB host mode (USB0 to ethernet adapter) : Good

4. Hot swapping from USB host mode (USB0 to ethernet adapter) to RNDIS USB device mode : Failure  

  • Hi Matt,

    4. Hot swapping from USB host mode (USB0 to ethernet adapter) to RNDIS USB device mode : Failure  

    Please explain the test procedure, how did you exactly do the "how swapping" test.

  • 1. USB0 is connected to ethernet adapter (RJ45). The laptop can ping H/W board through the path (Laptop - Ethernet Switch - ethernet adapter - H/W board with TI processor).

    2. Disconnect ethernet adapter

    3. Plug RNDIS cable (USB-A to micro USB) into USB0 of H/W board. Please make sure the connection (H/W board with Ti processor - USB0 - RNDIS cable - laptop)

    4. The laptop tries to ping H/W board.

    After step3, the laptop complains about unrecognized USB connection on Windows device manager. Step 4 fails. 

    If I skip step 1 & 2 (namely NOT try to connect USB0 to ethernet adapter), step 3 & 4 work well.

  • Can the issue be reproduced with AM437x GPEVM USB0 port?

  • Yes. I could. I will double check it again.

  • Thanks.

    If you can replicate the issue on the GPEVM, please also test it with a Linux host if you have one, since I don't have access to a Windows computer recently.

  • Mostly hot swapping between ethernet adapter and RNDIS is working well on GPEVM. I saw the same issue once but the issue was gone after one more hot swapping. I would check the USB H/W schematic with H/W engineering team. Do you have any advice which may be helpful for debugging the issue?

  • This is the first time I hear this type is issue, so not sure what could be the root cause. But here are my few comments:

    - test your custom board with a Linux PC instead of Windows. Linux host dmesg log provides more USB enumeration information than Windows does;

    - check the VBUS line voltage when hot swapping, and ensure VBUS drops to near 0v before the next connection. Otherwise, the USB controller might have unexpected behavior.

  • I suspect the VBUS voltage when hot swapping as well. I will update the status of issue after checking it with H/W engineer.

  • After step2 "Disconnect ethernet adapter", VBUS stayed around 2.3V. H/W engineer has been checking what prevents VBUS to drop to near 0v. BTW, when RNDIS USB is connected as USB device, VBUS 5V is okay? or VBUS shall be 0V when RNDIS is connected. I thought VBUS is High only when USB host is connected.

  • After step2 "Disconnect ethernet adapter", VBUS stayed around 2.3V. H/W engineer has been checking what prevents VBUS to drop to near 0v.

    Please first check if the USBx_DRVVBUS pin is low after the disconnect. I will think so, since VBUS is 2.3v, not 5V. But please double check.

    when RNDIS USB is connected as USB device, VBUS 5V is okay?

    Do you mean when RNDIS gadget driver is loaded on AM437x and its USB port is connected to a USB host? If so, yes VBUS should be 5v in such case, the 5v comes from the VBUS line on the host USB port.

  • USB0_DRVVBUS is low after the disconnect. USBx_DRVVBUS looks working fine.

  • Okay, it is expected.

    It seems to be a problem in the VBUS draining path.

  • Hi Bin, 

    I'm the HW person assisting Matt L. on this issue. He tested the USB Host/Device swap with the AM4378 Starter Kit, not the GP EVM. 

    Our design looks somewhat similar to what is on the GP EVM, with the exception of the VBUS Driver and the ESD Protection. We are currently using the TPD6E004RSER for our USB ESD protection (VBUS connects to VCC on the TPD6E004SER), the GP EVM and Starter Kit EVM use the TPD4S012. Our VBUS driver is the AP2171WG-7. Matt and I have confirmed that USB0_DRVVBUS is working as intended to enable our BUS Load Switch for Host Mode. When switching to device mode, we see USB0_DRVVBUS low (we also have a 10k PD on the EN line as well). ID pin connects directly from the Micro-USB connector to the MPU. We do have about 120 uF capacitance on our VBUS line for host mode. 

    You've mentioned that the problem is in the VBUS draining path. We did have a 90.9 kOhm PD resistor on VUSB_VBUS, however, we still saw 2.3V on the VBUS line after disconnecting from a host or device. What type of VBUS draining path do you recommend and why doesn't either EVM boards have a draining path? 

    Thanks and hope to hear back soon! 

  • HI OscarZ,

    Sorry I am an sw buy, and really don't know much about the analog side of the hardware design, and not sure how exactly to drain path of VBUS. But one thing I am sure it is wrong that the 120uF CAP shouldn't be there,

    The USB Spec requires minimum 120uF CAP on the USB host port to avoid VBUS droop when USB device attached, but the USB Spec also requires the USB devices shouldn't have more than 10uF CAP for the same reason.

    So we typically add ~7uF CAP for the USB dual-role port, of cause this small CAP will limit on some devices attached.

  • Bin, 

    Thanks, this helped me understand the eval schematic. We will remove the bulk capacitance and reduce it to 4.7 uF for dual role purposes. We will also test it with our external host and devices to make sure they comply with updated capacitance values on VBUS.