Intermittent problem with USB enumeration on Verdin IMX8MP

Technical Support
, ,
1

Hello,

I have a custom carrier board that uses the Verdin imx8mp, and includes USB connection to a cellular modem. My design was working great on the Dahlia carrier board, but I am seeing that sometimes when I power on the USB modem, it does not properly enumerate on the USB bus.

I will get (in dmesg)

[ 1497.342908] usb 1-1: new high-speed USB device number 4 using xhci-hcd
[ 1497.474964] usb 1-1: Device not responding to setup address.
[ 1497.686933] usb 1-1: Device not responding to setup address.
[ 1497.898911] usb 1-1: device not accepting address 4, error -71

These failures happen roughly 1/3 of the time when I power up the USB board; the other 2/3 of the time is works perfectly, and stays up for over 24 hours with zero issues.

We do not use a hub controller IC, but connect the modem directly to the SOM as follows:

image
image897×583 15.2 KB

image
image727×962 17.1 KB

Do you have any advice for what we could try to do to fix or further troubleshoot this issue?

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello!

I understand you’re facing USB enumeration issues on your custom board, which previously worked on the Dahlia carrier board. Here are some software and system configuration aspects you might consider checking:

  1. USB Configuration in Software:

    • Ensure that the USB settings in your device tree are correctly configured for your custom board. Compare these settings with those used on the Dahlia carrier board to identify any discrepancies.

  2. Power Management Settings:

    • Verify that the power management settings in your software are optimized for your custom board. This includes ensuring that the USB power delivery settings are correctly configured.

  3. Kernel and Driver Updates:

    • Make sure your Linux kernel and USB drivers are up to date. Sometimes, updates can resolve compatibility issues that affect USB enumeration.

  4. Testing with Different Power Sources:

    • If possible, test your custom board with different power sources to see if the issue persists. This can help determine if power stability is a factor.

  5. Logs and Diagnostics:

    • Check system logs for any error messages related to USB enumeration. This can provide clues about what might be going wrong.

By focusing on these areas, you may be able to identify and resolve the USB enumeration issues on your custom board. If you need further assistance, feel free to ask!

Best regards,
Toradex AI Assistant

3

Could be a VBUS stability issue: The modem may not have stable VBUS or internal power when the host controller initiates enumeration.
Make sure the VBUS (5V) powering the modem is fully stabilized before the USB controller starts. If needed, add the startup-delay-us to the regulator to ensure proper timing.

Does your modem have a reset line? If so, consider adding a GPIO-controlled reset and asserting it during boot or when enumeration fails. This can help recover from startup timing issues.

4

I do have a gpio-controlled reset line. I can manually toggle it to reset the modem, and this sometimes, but not always solves the problem (roughly the same percentage of the time that of the modem appearing on start-up).

Will investigate adding the startup-delay-us to the regulator… does that only impact how long after bootup the regulator turns on? I’m not entirely clear on what that setting accomplishes.

Thanks for the feedback!

5

This delay ensures the regulator waits a specified time (in microseconds) before being considered “enabled” — useful when powering up devices like USB modems that need a bit of time to stabilize.

6

The delay does not appear to solve the problem.

We are using a modem socket that allows us to try different modems, we are currently trying a Quectel which does not have VBUS (and which was working perfectly with the dev kit, though there was a 4-port hub in that design and our carrier does not have one). Will see if there is any different behavior with a semtech modem.

7

Sounds like a signal integrity issue. Have you followed the Carrier Board Layout Guide recommendations when routing the USB signals?

8

Please note that the SSTX lines already have AC coupling capacitors on the module, so you don’t need to include them on your carrier board.

image
image1228×634 54.5 KB

image
image1166×252 45.5 KB

9

That is likely our problem! We are doing a device-down USB connection, but your point remains valid – our caps are on the wrong pair of superspeed lines!

Thank you so much for bringing that to our attention.

10

Most likely, the modem will also have capacitors on the other signal pair.

11

You are correct - all modems we are considering for this design already have those ac-coupling capacitors (typically 220nF in).

We were able to pinpoint the root cause of our problem: the SSTX pair was going to the modem transmit pins of the modem, and the SSRX pair was going to the modem receive pins. By correcting this pair and relying on the on-SoM and on-Modem coupling caps, we are now working very reliably.

Thanks!

12

OK, so we were able to do some PCB surgery and swap the USB lines, and now the modem enumerates properly every single time. Progress!

I am able to use the modem just fine, and the download/upload speeds are acceptable. The only lingering issue is that there is a new kernel warning when I check dmesg, and it repeats every four seconds…

[ 880.549483] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 880.549508] usb usb2-port1: config error
[ 880.553501] usb usb2-port1: do warm reset, port only
[ 880.610800] usb usb2-port1: not warm reset yet, waiting 50ms
[ 880.670793] usb usb2-port1: not warm reset yet, waiting 200ms
[ 880.878799] usb usb2-port1: not warm reset yet, waiting 200ms
[ 881.086794] usb usb2-port1: not warm reset yet, waiting 200ms
[ 881.294790] usb usb2-port1: not warm reset yet, waiting 200ms
[ 881.294859] usb usb2-port1: not enabled, trying warm reset again…
[ 881.502803] usb usb2-port1: not warm reset yet, waiting 200ms
[ 881.710775] usb usb2-port1: not warm reset yet, waiting 200ms
[ 881.918771] usb usb2-port1: not warm reset yet, waiting 200ms
[ 882.126776] usb usb2-port1: not warm reset yet, waiting 200ms
[ 882.126849] usb usb2-port1: not enabled, trying warm reset again…
[ 882.334764] usb usb2-port1: not warm reset yet, waiting 200ms
[ 882.542774] usb usb2-port1: not warm reset yet, waiting 200ms
[ 882.750758] usb usb2-port1: not warm reset yet, waiting 200ms
[ 882.958769] usb usb2-port1: not warm reset yet, waiting 200ms
[ 882.958849] usb usb2-port1: not enabled, trying warm reset again…
[ 883.166771] usb usb2-port1: not warm reset yet, waiting 200ms
[ 883.374751] usb usb2-port1: not warm reset yet, waiting 200ms
[ 883.582746] usb usb2-port1: not warm reset yet, waiting 200ms
[ 883.790738] usb usb2-port1: not warm reset yet, waiting 200ms
[ 883.790806] usb usb2-port1: not enabled, trying warm reset again…
[ 883.998738] usb usb2-port1: not warm reset yet, waiting 200ms
[ 884.206735] usb usb2-port1: not warm reset yet, waiting 200ms
[ 884.414736] usb usb2-port1: not warm reset yet, waiting 200ms
[ 884.622736] usb usb2-port1: not warm reset yet, waiting 200ms
[ 884.622813] usb usb2-port1: not enabled, trying warm reset again…
[ 884.622823] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?

I am unsure of whether this is caused by the PCB surgery we did, or whether there is another issue with our device tree or settings. These warnings were not there previously.

13

Could you attach the full boot log as a text file?

14

bootlog.txt (52.0 KB)

Here is the dmesg output from the latest reboot.

15 
[    6.881747] hub 2-0:1.0: USB hub found
[    6.897130] hub 2-0:1.0: 1 port detected
[    7.173798] usb usb2-port1: config error

What other devices do you have connected to the Verdin USB on your carrier board?

16

None at all.

image

17

The lsusb output isn’t a valid answer in this case — it won’t show devices that failed to enumerate. Could you share the part of your schematic related to the USB_1 interface?

18

I will get that to you shortly. I greatly appreciate your help.

19

Most likely, there are some shorts or electrical interference on the USB_1 pins — possibly caused by the ‘surgery’ you performed. This may be interpreted by the USB driver as a plug-in event, triggering an enumeration attempt with a non-existent device, which of course fails.

If you’re unable to fix this on your board, you can disable USB_1 support in software by disabling its Device Tree node:

&usb_dwc3_0 {
    status = "disabled";
};
20

USB_1 pins are all no connect. We will inspect for shorts.

I disabled usb_dwc3_0 in the device tree as you stated, with no change in behavior - still that bad cable warning every 4 seconds.

But isn’t this warning related to USB_2, not USB_1?