Xavier AGX devkit front USB-C: Cannot enable, maybe the USB cable is bad?

Hi, I have this problem on at least two of our Xavier AGX devkits, thus I extrapolate it happens generally and is not caused by a faulty Jetson. The Jetsons run latest vanilla L4T from JetPack 4.6, no customizations.

Many USB devices I connect do not work in the front USB-C (the flashing port), but they do work in the rear USB-C. The error in dmesg is:

usb usb2-port3: Cannot enable. Maybe the USB cable is bad?

This keeps repeating forever (or until I disconnect the device).

What works in both:

  • SATA disk USB enclosure (2109:0715)

What works only in rear port:

  • USB hub (2109:0822, coolgear)
  • USB-C flash disk (0781:5595)

It doesn’t matter whether I connect these devices to a running system or boot with them, the behavior is always the same.

I tried booting with usbcore.autosuspend=-1 (as mentioned in USB C Ports Jetson AGX Xavier stopped working - #2 by linuxdev). It changed nothing (and I saw the option applied in /proc/cmdline).

Here I attach a debug USB log when connecting the USB hub (which fails): dmesg.jetson (172.2 KB)

Hi,
Could you flash Jetpack 4.5 for a try? Would like to know if it is specific to Jetpack 4.6. Or not related to release versions.

Hi, this has been happening to us since July (have not tried before), so it is not 4.6-specific.

Hi,
If the issue is specific to certain Xavier modules, you may consider to do RMA:
Jetson FAQ | NVIDIA Developer

We would suggest try other L4T releases such as Jetpack 4.4, Jetpack 4.5. Or more USB devices to confirm it surely is an issue in the module.

Tested on a 3rd unit (# R32 (release), REVISION: 5.1, GCID: 27362550, BOARD: t186ref, EABI: aarch64, DATE: Wed May 19 18:16:00 UTC 2021). The behavior is exactly the same. As I said, all tested devices behave normally in the rear port, so it’s definitely not an issue with the devices themselves.

Here are the USB packet captures.

You can see from the captures that if things go well, the rear and front ports behave exactly the same. However, if things go bad, even the first status request has a different response than in the successful cases (it’s missing PORT_CONNECTION and PORT_ENABLE flags). The status requests coming from the host are the same. Thus it seems to me it has to be some kind of electrical incompatibility (i.e. the hub is not powered on correctly or so).

I am also a developer kit user and have the same problem. I tried a 1.5-meter USB extension cable. My solution when I run into problems is to plug and unplug the USB port (sometimes only half the length of the port) and the device will work and stay fine. I’m guessing it’s a power supply problem or emc problem.

Hi,
The default setting on Xavier developer kit is tuned with connecting to devices directly. If your usecase requires long cable, it may have issues in signal quality. For this use-case, it may be better to design your own custom board and perform compliance test.

That’s probably a different issue. The devices I am trying are connected either directly (flash drive) or via a short cable.

I’m also using the original power supply plugged in a standard wall socket.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

@DaneLLL some time has passed and the problem still persists. I have provided a lot of debug info, tested the issue on multiple units with Jetpack 4.5 or 4.6 and it can be triggered consistently. Could you please help us resolving this issue?

Hi,
We would need to reproduce the issue and do debugging. Please provide steps for reproducing the issue on Xavier developer kit. What is the USB device in your setup? A camera or a pendrive?

And have you tried other cables? The print shows signal quality is not good.

usb usb2-port3: Cannot enable. Maybe the USB cable is bad?

All needed information is provided in the issue description in post 1.

There is no cable when I connect a pen drive. So it can’t be bad. All the devices work ok in rear port, so that rules out any kind of damaged/misbehaving reasons.

Steps to reproduce:

  1. Start Jetson AGX
  2. Run around your office, collect as many USB-C devices as you can
  3. Connect them to the front (flashing) USB-C port.
  4. Some of the devices will probably show the “cannot enable” error and will not work.
  5. Plug these non-working devices into the rear port. They will probably work.

If you wanted to buy the exact flash drive I used for the test, it should be this one: https://www.amazon.com/SanDisk-128GB-Ultra-Drive-Type-C/dp/B01EZ0X55C?th=1 .

@DaneLLL Could you also test with Jetpack 5.0? Maybe the problem will be solved by the newer kernel…

Hi,
We try with Sandisk pendrive and it is detected in both ports:

[90023.273380] ucsi_ccg 1-0008: port1 evt: Type-C Port Connect Detected
[90023.275255] ucsi_ccg 1-0008: [typec-port1] Cable state:1, cable id:2
[90023.771097] usb 2-1: new SuperSpeed USB device number 4 using tegra-xusb
[90023.792168] usb 2-1: New USB device found, idVendor=0781, idProduct=55a9
[90023.792181] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[90023.792186] usb 2-1: Product:  SanDisk 3.2Gen1
[90023.792191] usb 2-1: Manufacturer:  USB
[90023.792197] usb 2-1: SerialNumber: 01014c1075567a64d07063139545fcd23922ee021e
8acff52f76e2038520bbb47cd6000000000000000000000028beabff1d0200a95581075b2b5d1c
[90023.794109] usb-storage 2-1:1.0: USB Mass Storage device detected
[90023.799798] scsi host2: usb-storage 2-1:1.0
[90024.823959] scsi 2:0:0:0: Direct-Access      USB      SanDisk 3.2Gen1 1.00 PQ
: 0 ANSI: 6
[90024.825528] sd 2:0:0:0: [sda] 240353280 512-byte logical blocks: (123 GB/115
GiB)
[90024.828477] sd 2:0:0:0: [sda] Write Protect is off
[90024.828651] sd 2:0:0:0: [sda] Mode Sense: 43 00 00 00
[90024.829201] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doe
sn't support DPO or FUA
[90024.841522]  sda: sda1
[90024.845276] sd 2:0:0:0: [sda] Attached SCSI removable disk

Not sure if it helps but could you try Jetpack 4.6.1?

Now I’m confused with my previous observations - maybe I swapped the meaning of front and rear USB-C. In the first post, I say that by front connector I mean the flashing one, but that is no longer in match with what I observe now.

So let’s get this straightened up. The failing port is reported in dmesg as typec-port0. That corresponds to the connector on the side where there is just the USB-C and a micro USB. The other port near the power jack input is reported by dmesg as typec-port1. So let’s use these identifiers.

Now, if you look at the dmesg output I attached to the first post, it clearly says the problem was detected on typec-port0. That’s in contradiction with me telling that it is the front (flashing) port. I’m sorry for the confusion. The problematic port has always been typec-port0.

I retested with Jetpack 4.6.1 /L4T 32.7.1/ and nothing changed. Hub plugged in typec-port0 doesn’t work while it does in typec-port1.

Thank you for testing with the flash disk you found. It is not exactly the same I use - yours is 0781:55a9, mine is 0781:5595. You will probably need to get a few more USB-C devices to discover which ones trigger this bug.

Thank you for helping us resolve this issue.

Hi,
We have tried both type-C ports and do not observe the issue. Looks like the issue is specific to the pendrive you have. Would suggest you try other pendrives or devices if possible.

Please, read the first post again. I’ve tried many devices. Some work in both ports, some work only in typec-port1. And the results are exactly replicated on different pieces of AGX Xavier with L4T 32.5-32.7 and on different pieces of the same USB hardware. Please try connecting more devices (USB ethernet cards, other pendrives etc.).