USB stops getting recognized

Technical Support
, ,
1

Hi,

Setup:
Verdin iMX8MM DL 1GB WB IT V1.1B
TorizonCore 5.5.0
Verdin Development Board V1.1A

We are experiencing USB issues on our custom board. As long as one device is plugged in and active on one port (has to be connected during boot), the other port keeps working. Whenever both ports have no devices plugged in, from then on no devices are getting recognized on both ports.

We tried to recreate the behaviour on the development board to rule out a hardware issue.
We are using an unmodified TorizonCore 5.5.0 build.
To make sure no devices are active on both ports on the dev board, we disable the USB hub (IC11, X53) by pulling EX_1 low (by placing a 100 Ohm resistor between X8A & X8B), which causes PWR_CTRL_1 to stay low, disabling power to the hub.
For easier testing multiple USB devices on the USB DRP port (X34), we use a USB type C plug to type A receptacle cable adaptor. (Pro Signal PSG91481; datasheet)
This USBC cable adaptor is plugged in all the time. Connecting/disconnecting devices happens at the type A receptacle side of the adaptor.
‘lsusb --tree’ is used to view the list of connected USB devices.

If a device is plugged in during boot, it works. After disconnecting once, the port stops working. Reconnecting the device does nothing, the device is not getting recognized?
If no device is plugged in during boot, the port never works.
If the hub is active on the other port during boot (IC11; remove the resistor between X8A & X8B before boot), the port does keep working all the time.

Only when we get to a point where no devices are connected on both ports, the ports stop working.
Any idea why USB devices stop getting recognized in this situation?

Best regards,
Frederik

2

Dear Frederik, hope you’re doing great!

Before we could investigate your issue with further details, we’d like to ask you a few questions about it.

  • If I understood well your problem, you’re experiencing a problem with the USB Ports on your custom carrier board that you’ve been able to reproduce on our Development Board by disabling the USB Hub, right? Why did you manipulate the USB Hub (USB_2 Port) even though your test is related to USB C (USB_1 Port)?

  • Have you tried using another USB Type C to Type A adaptor during your tests?

  • On your custom carrier board, do you use USBs Type A only, Type C only, or both?

  • Can you please send us the Schematics of your custom carrier board so that we could check for any design incompatibilities? You can send them via e-mail to support.eu@toradex.com

Best Regards,
Guilherme

3

Hi Guilherme,

Thanks for looking into our issue.

  • We disabled the hub to get a setup with the dev board where no devices are connected on both USB ports. The problem only occurs after nothing is connected on both ports.

  • We have not tried using other C-to-A adaptors, but the one we are using works perfectly with multiple other USB-C hosts.

  • Our custom carrier board uses USB_2 internally, and has a USB-C connector on USB_1. I would like to focus on the dev board for now, as the problem also occurs there.

A few day ago, I noticed issue ELB-4268 on the issue tracker:

Description: Hot-plugging USB devices on the USB host port USB_2 does not work on a custom carrier board without a USB hub in-between. Note that current Toradex carrier boards (Dahlia and the Verdin Development Board) do have such a USB hub and therefore do NOT exhibit this issue as the USB hub itself is handling the hot-plugging.

This sounds very similar to the issue we are having…

Workaround: This issue is related to USB suspend/resume and may be worked around by disabling USB ports ever entering suspend. The relevant function would be imx_controller_suspend() in drivers/usb/chipidea/ci_hdrc_imx.c (e.g. just returning zero instead of doing anything).

And this workaround does indeed fix our issue.

So, by disabling the hub, this issue can be recreated on the dev board. It is not limited to port USB_2, but also occurs on USB_1 when using a C-to-A adaptor.

Both USB ports are now working on our custom board, and we can continue development.
Our device is battery powered, so we want power consumption to be as low as possible. Any idea how much disabling USB suspend affects power consumption?
Any estimate on when this issue might get fixed, so we don’t have to rely on the workaround?

Best regards,
Frederik

4

Hi @dekfrederiks , hope you’re doing great!

Thanks for your feedback and it’s good to hear that the workaround helped you deal with your issue.

I’ve discussed this with our team to check about your issue that seems the same one presented on the issue tracker. Currently, there are people working on it from our side but we can’t give any time estimation right now of when it will get corrected. Once the tests are over and we have the issue properly addressed we’ll get back to you.

Finally, regarding the power consumption, it doesn’t seem to us, something that would critically increase it.

Best regards,
Guilherme

5

Hi @dekfrederiks , how are you?

We had a piece of new information from NXP about what could be causing this issue so that you don’t need to rely on the workaround. Can you please check that the USB_ID pin is down when in host mode? The carrier board should pull this pin down when. If it’s still up, it can cause the problem you’re experiencing.

Best regards,
Guilherme

6

Hi @dekfrederiks !

We have a new workaround for this issue.

diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
index eb9cf2576bf7..45513d609822 100755
--- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
@@ -769,6 +769,7 @@
 
 &usbphynop2 {
        vcc-supply = <&reg_aux_usb>;
+       power-domains = <&usb_otg2_pd>;
 };
 
 /* On-module eMMC */

Could you please test it and let us know if it works for you?

Thanks in advance!

Best regards,

1 Like