We are using an Orin NX in an Orin Nano Devkit and have run into an issue with the USB-C port.
The issue is that after running a number of consecutive USB loopback tests, the loopback plug stops being detected/usable by the test software and after swapping to a flash drive in the same port, the drive is not detected/enumerated. Oddly, the test plug still appears in lsusb in this state, even after switching to the flash drive. The only printouts in dmesg when unplugging/plugging devices in this state come from the fusb301 controller. After replugging several times the problem recovered and the flash drive was detected. Is this any sort of known issue, or can anyone explain the behavior?
L4T version is 36.4.3. Dmesg is attached, you can see the repeated loopback test as a number of repeated USB disconnect/new USB device, followed by a number of disconnects/reconnects reported by the controller, followed by the USB Mass Storage device detected when the problem recovered.
*** Please note that this reply is generated by LLM automatically ***
The issue you’re experiencing with the USBC port on the Jetson Orin NX module in an Orin Nano Devkit seems to be related to a known problem with the USB controller.
After analyzing the provided dmesg log, it appears that the issue is caused by the fusb301 controller, which is responsible for managing the USB ports on the Jetson Orin NX module. The repeated loopback tests seem to be causing the controller to enter a state where it’s unable to detect or enumerate new devices, even though the devices are still visible in the lsusb output.
This behavior is similar to a known issue with the fusb301 controller on the Jetson Orin NX module, where the controller can become unresponsive after a large number of consecutive USB disconnects and reconnects. This issue is often referred to as a “USB controller hang” or “USB port hang.”
To resolve this issue, you can try the following:
Power cycle the Jetson Orin NX module: Sometimes, simply power cycling the module can resolve the issue.
Disable and re-enable the USB controller: You can try disabling and re-enabling the fusb301 controller using the following commands:
Update the L4T version: You’re currently running L4T version 3643. You may want to check if there are any updates available for the L4T version, as newer versions may include fixes for this issue.
Use a different USB port: If the issue persists, you can try using a different USB port on the Jetson Orin NX module to see if the problem is specific to the USBC port.
It’s worth noting that this issue may be specific to the Jetson Orin NX module in an Orin Nano Devkit, and may not be present on other Jetson Orin NX modules or configurations.
In comparison to other Jetson modules, the Jetson Orin NX module has a similar USB controller architecture, but the specific implementation and configuration may differ. Therefore, it’s possible that this issue may not be present on other Jetson modules, such as the Jetson Orin Nano or Jetson AGX Orin.
However, if you’re experiencing similar issues with other Jetson modules, you may want to try the same troubleshooting steps to see if they resolve the issue.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Exactly, lsusb still shows the test plug even though it has been swapped out for a flash drive, and the flash drive does not appear. Also with nothing in the port, still shows the old device
Hi, sorry for the delay. I modified some printout and I can see that the patch applied correctly. Still possible to reproduce the issue. See dmesg below with the modified print and lsusb showing the test plug even after removing it from the port:
[ 1252.402433] tegra-xusb 3610000.usb: Blah Blah Blah Firmware timestamp: 2023-02-10 03:48:10 UTC
[ 1253.264814] usb 2-2: new SuperSpeed USB device number 24 using tegra-xusb
[ 1253.286543] usb 2-2: LPM exit latency is zeroed, disabling LPM.
[ 1276.368895] fusb301 1-0025: fusb301_work_handler: int_sts[0x02]
[ 1276.368904] fusb301 1-0025: fusb301_detach: type[0x10] chipstate[0x07]
[ 1276.370052] fusb301 1-0025: fusb301_set_mode: mode (32)(32)
[ 1276.370378] fusb301 1-0025: fusb_update_state: 1
shotover@nx-devkit-004:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0bda:5489 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 0bda:0489 Realtek Semiconductor Corp. 4-Port USB 3.0 Hub
Bus 002 Device 024: ID 0403:ff0b Future Technology Devices International, Ltd USB3Test
I’m not really a “USB3 guy”, but my understanding is that the fusb301 itself uses i2c to communicate details like role and USB detection. Have you tried a USB3 analyzer on the port to determine if the failure shows up in detection? If detection shows up at the PHY of the USB-C connector, then it would imply any failure is in the i2c side or the device tree. I don’t really know if there is such a thing as a logging mode for the particular i2c part of this, but if so, then logs which also state what the i2c is doing could say a lot about the cause.