Issues connecting USB devices to USB OTG

jbruno · August 27, 2024, 7:41am

Dear community,

When connecting some USB devices to the X3 connector (USB-C OTG) of the Dahlia card I get the following error:

[  252.317174] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[  252.322743] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 3
[  252.330796] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220fe65 hci version 0x110 quirks 0x0000002001010010
[  252.340261] xhci-hcd xhci-hcd.2.auto: irq 78, io mem 0x38100000
[  252.346304] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[  252.351827] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 4
[  252.359524] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0 SuperSpeed
[  252.366540] hub 3-0:1.0: USB hub found
[  252.370372] hub 3-0:1.0: 1 port detected
[  252.375508] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[  252.384162] hub 4-0:1.0: USB hub found
[  252.388010] hub 4-0:1.0: 1 port detected
[  253.356684] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[  263.660765] xhci-hcd xhci-hcd.2.auto: Abort failed to stop command ring: -110
[  263.678012] xhci-hcd xhci-hcd.2.auto: xHCI host controller not responding, assume dead
[  263.685949] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[  263.691538] xhci-hcd xhci-hcd.2.auto: Timeout while waiting for configure endpoint command
[  263.700038] usb 3-1: can't set config #1, error -62
[  263.705203] usb 3-1: USB disconnect, device number 2

I have tried with different devices and it does not fail with all, but I have repeated the same test with a Verdin iMX8M mini module and this error does not appear. What is the reason for this difference in behavior? How can it be fixed?

The SW and HW I have used for these tests is the following:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.148-6.7.0+git.bfdbfb2c85fb #1 SMP PREEMPT Thu Jun 20 15:59:41 UTC 2024
Kernel command line:      root=PARTUUID=fac5235d-02 ro rootwait console=tty1 console=ttymxc2,115200 consoleblank=0 earlycon
Distro name:              NAME="TDX Wayland with XWayland"
Distro version:           VERSION_ID=6.7.0-build.13
Distro variant:           -
Hostname:                 verdin-imx8mp-14740793
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0058 V1.1A
Serial number:            14740793
Processor arch:           aarch64
------------------------------------------------------------

Best regards,
Julián

ToradexAI · August 27, 2024, 7:42am

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

The issue you’re encountering with the USB OTG on the Dahlia carrier board could be related to several factors, including differences in hardware configuration, USB controller behavior, or software settings between the Verdin iMX8M Plus and the Verdin iMX8M Mini modules.

Here are a few steps to help diagnose and potentially resolve the issue:

Check Power Supply: Ensure that the power supply to the Dahlia board is sufficient, especially when connecting high-power USB devices. Insufficient power can cause the USB controller to behave unpredictably.
USB Cable and Devices: Verify that the USB cable and devices you are using are functioning correctly. Sometimes, faulty cables or devices can cause intermittent issues.
Kernel Configuration: There might be differences in the kernel configuration between the two modules. Ensure that the kernel configuration for USB support is consistent across both modules. Specifically, check the xhci-hcd driver settings.
USB Controller Firmware: The USB controller firmware might differ between the two modules. Ensure that both modules are running the same firmware version for the USB controller.
Device Tree Configuration: Differences in the device tree configuration can also lead to such issues. Compare the device tree files for both modules to ensure that the USB OTG settings are consistent.
Kernel Logs: The error logs indicate issues with the xHCI host controller. You might want to enable more verbose logging for the USB subsystem to get additional insights. This can be done by adding usbcore.autosuspend=-1 to the kernel command line to disable USB autosuspend and see if it affects the behavior.
Software Updates: Ensure that both modules are running the latest software updates. Sometimes, bugs in the USB stack can be resolved with newer software versions.
USB Hub Control: If you are using a USB hub, ensure that it is properly powered and configured. You can use the uhubctl tool to manage the power to the USB ports and see if it helps in stabilizing the connection.

If the issue persists after trying these steps, it might be helpful to isolate whether the problem is hardware-specific or software-specific by testing with different combinations of hardware and software.

Best regards,
Toradex AI Assistant

bruno.tx · August 27, 2024, 6:51pm

Hello @jbruno,

I am able to reproduce this issue here.
It looks like the regulator that enables the power to the port while the Verdin Module is acting as a host is not being toggled with the Verdin iMX8MP.
This is likely a device tree issue, but I will continue to investigate this problem and send updates when there is a solution.

Best Regards,
Bruno

bruno.tx · August 28, 2024, 5:51pm

Hello @jbruno,

Investigating this further, I was actually having this issue with an older hardware revision: 0058 V1.0B.
When testing 0058 V1.1A* the devices were properly recognized via the OTG port.

Which devices are you having issues with?
Is the current limit of 1A for the port being respected?

* Edit: The version of the module which the devices worked was mistakenly mentioned as V1.0B.

Best Regards,
Bruno

jbruno · August 29, 2024, 7:04am

Hi @bruno.tx ,
We are connecting a USB camera whose current consumption is less than 500 mA.
Best regards,
Julián

jbruno · August 29, 2024, 7:18am

Hi @bruno.tx ,
To rule out a bug related to the fact that your default images are configured for the DEV card and not for the Dahlia card, I have reconfigured the system as follows:

fw_setenv board 'dahlia-imx8mp'
fw_setenv board_name 'dahlia-imx8mp'
fw_setenv fdt_board 'dahlia'
fw_setenv fdtfile 'imx8mp-verdin-wifi-dahlia.dtb'
reboot

I have repeated the tests and the failure persists.

Best regards,
Julián

bruno.tx · August 29, 2024, 5:17pm

Hello @jbruno,

First, I need to make a correction, on my previous post I forgot to correctly state the hardware version in which the USB DRP worked for me: it was 0058 V1.1A, the same version you have. The post has been updated accordingly.

Thanks for the additional details and tests.
I believe the issue is not directly related to the OTG port, as in your other post you had the same problem in a standard USB A port.
This may be related to the driver being used for the USB port, as the i.MX8M Plus has a USB 3.0 controller (XHCI) and the i.MX8M Mini has a USB 2.0 controller (EHCI).
The XHCI driver is used even when in USB 2.0 mode, and seems to be correctly identifying the camera as a USB 2.0 device:

Which exact camera are you experiencing this problem?
Is any other USB device not working in a similar way with the Verdin iMX8M Plus?
If you prefer, this information can be sent with a message to the moderators here on the community or via support.eu@toradex.com.

Can you also test this on one of the USB-A ports in the Dahlia Carrier Board?
These ports go through a USB hub, but it would be good to understand if the problem is also present there.

Best Regards,
Bruno

msv_zitnik · September 26, 2024, 12:56pm

Hi @bruno.tx

We have the same problem with enumeration over xhci-auto. Command ring finishes handshake with abortion and -ETIMEDOUT (110)
As far as I investigated, it is some problem with xHCI/USB3.

We have 2 different devices:
Device no. #1, M.2 slot connected directly to USB_1 (without hub)
Device no. #2, M.2 slot connected directly to USB_2 (without hub)

In both devices, GSM module Simcom SIM7600G-H-M2 R2 placed into M.2 and works perfectly. Also, another module, Quectel RM500U-EA works perfectly.

Unfortunately, We need Quectel RG255C-GL, because it have smaller form-factor then RM500U (42x30 instead of 52x30)

Now, Quectel RG255C-GL raises errors with xhci-hcd and I am out of any ideas what to do.

[   70.999255] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[   81.331252] xhci-hcd xhci-hcd.1.auto: Abort failed to stop command ring: -110
[   81.354523] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
[   81.362449] xhci-hcd xhci-hcd.1.auto: HC died; cleaning up
[   81.368045] xhci-hcd xhci-hcd.1.auto: Timeout while waiting for configure endpoint command
[   81.376359] usb 1-1: can't set config #1, error -62
[   81.381447] usb 1-1: USB disconnect, device number 2

We tried connect this modem to PC (x86, linux 6.10.10) via USB (USB3.1port) and everything seems to be OK:

[  625.427686] usb 3-1: new high-speed USB device number 20 using xhci_hcd
[  625.570428] usb 3-1: New USB device found, idVendor=2c7c, idProduct=0316, bcdDevice= 5.15
[  625.570450] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  625.570457] usb 3-1: Product: RG255C-GL
[  625.570461] usb 3-1: Manufacturer: Quectel
[  625.570466] usb 3-1: SerialNumber: 9150cda5
[ 1368.719469] usbcore: registered new interface driver option

Host mode enforced in DTS:

&usb_dwc3_0 {
	status = "okay";
	dr_mode = "host";
};

Strange and important fact is, modem is working on Verdin Evaluation board connected over USB HUB (X53 connector)

If I connect this modem to our board over USB HUB, it works.

Verdin Development Board, connector X34 (USB_1, type C) - Same error as in our board
Verdin Development Board, connector X53 (USB_2, type A) - OK (because it is via USB hub)
Verdin Development Board, connector X34 (USB_1, type C) + external USB 2.0 hub - OK

Note:
We tried your Reference Minimal Image with kernel 5.15.148-6.7.0+git.bfdbfb2c85fb and our custom yocto system with kernel 5.4.193-6.7.0-devel-6.7.0-devel+g03b3ba4a8. There is no difference.

Thank you for any advice.

bruno.tx · October 1, 2024, 3:23pm

Hello @msv_zitnik,

Thanks for the detailed explanation.
I was able to reproduce this issue with another USB device.

What I can say is that this does not appear to be an issue unique to 5G modems, but we still need to investigate the cause of it.

I was also able to reproduce this behavior, which strongly indicates that the problem is related to a direct connection to one of the device’s USB port.

Once we have updates I will send them here.

Best Regards,
Bruno

bruno.tx · October 2, 2024, 12:25pm

Upon further investigation, the cause of the problem is still not clear.
It seems that it is related to the driver for the USB controller in the i.MX8M Plus.

Fortunately this problem is fixed in BSP 7, which has a newer kernel.
BSP 7 still does not have a stable release, but one will be released in the next few weeks.

@msv_zitnik, can you also test if you get the same results with your setup?
For my tests, I used the latest nightly image for BSP 7:
https://artifacts.toradex.com/ui/api/v1/download?repoKey=tdxref-oe-prerelease-frankfurt&path=scarthgap-7.x.y%2Fnightly%2F142%2Fverdin-imx8mp%2Ftdx-xwayland%2Ftdx-reference-multimedia-image%2Foedeploy%2FVerdin-iMX8MP_Reference-Multimedia-Image-Tezi_7.0.0-devel-20241001%2Bbuild.142.tar

Best Regards,
Bruno

msv_zitnik · October 3, 2024, 6:42am

Hi @bruno.tx

Thanks a lot for solution, new kernel works perfectly!!!