Hardware: Jetson Orin Nano Super Developer Kit (module P3767-0005, carrier P3768, TNSPEC 3767-300-0005-W.1...jetson-orin-nano-devkit-super).
Problem: None of the four USB-A host ports will enumerate any external device. Tested with a USB keyboard and a bare USB flash drive, in all four ports — nothing appears in lsusb, no block device, no input device.
What works: Onboard/internal USB is fine — the internal Bluetooth (13d3:3549) enumerates normally on every boot. Recovery mode + flashing over USB-C also work (I’ve reflashed the board twice successfully).
dmesg (repeats continuously when any device is plugged into a USB-A port):
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
On the USB2 side the device is detected but re-enumerates repeatedly and never completes (device numbers increment, no idVendor, keeps resetting).
Troubleshooting already done — the fault persists through all of it:
- Clean flash of JetPack 7.2 (L4T r39.2) — fails.
- Clean flash of JetPack 6.2 — still fails (rules out the JetPack/BSP version).
- Measured 5V on all four USB-A ports with a multimeter (VBUS is present).
- Multiple different devices (keyboard, flash drive) and all four ports.
- Power:
nvpmodel 25W mode, no undervoltage / over-current / throttle messages in dmesg.
- Not a cable issue (bare flash drive, no cable) and not brownout (a keyboard draws ~0).
- Firmware is version-matched (
nvbootctrl: QSPI/UEFI 39.2.0 = rootfs, both slots normal, capsule status 0).
Since this survives clean flashes of two different major JetPack versions, with VBUS present and internal USB working, it looks like a hardware fault on the external USB path. Can you confirm and advise on RMA? Happy to attach full dmesg or run any test you need.
Just to clarify. Was the type A on it ever working before?
Your crosscheck sounds like this issue has nothing to do with software version.
Is the USB mouse or keyboard showing up with powered when you connect it to the port?
Thanks for the follow-up, to answer your questions:
Yes, the Type-A ports worked when I first flashed the board. After that initial setup I boxed it since I didn’t need it right away. When I took it back out yesterday and reflashed to JetPack 7.2, all USB ports (four Type-A plus the Type-C data port) were dead.
And correct, my cross-checks confirm this isn’t software related. USB fails identically across fresh flashes of JetPack 7.2 and 6.2, and it’s dead at the UEFI level before any OS loads (a keyboard can’t navigate the UEFI menu).
On the power question: I measured 5V present at the ports, but nothing enumerates. A connected mouse or keyboard doesn’t show up in lsusb and no input/block device appears. So power is reaching the ports, but there’s no data enumeration on any of them.
Additional confirmation the controller itself is alive: the xHCI controller initializes cleanly (firmware loads, both buses register, USB 3.1 SuperSpeed detected), and the internal Bluetooth radio (13d3:3549) enumerates normally on every boot. dmesg shows “usb usb2-port1: Cannot enable. Maybe the USB cable is bad?”, but I’ve tried all four ports with multiple known-good cables and devices, and verified the genuine NVIDIA carrier on the included barrel-jack supply.
Given it worked at first flash and was dead at the UEFI level when I pulled it back out, this looks like a hardware failure in the carrier’s USB path.
Could you flash your board back to jp6.2.2 and then share me the log from uart?
It is actually strange that even type C is not working as you could still flash it.
This is a Orin Nano. If you know the flash mechanism, then you may understand that the hardware might not really in defect (at least for type C part).
Thanks for the follow-up. Before reflashing to JP6.2.2, I want to share a test result that I think isolates the issue.
I bought a second Orin Nano dev kit and moved the exact same NVMe (same JP7.2 image) into it, using the same cables and the same keyboard/mouse and flash drive. On the new board, everything works immediately — all four Type-A ports and the Type-C port enumerate normally. lsusb shows the Realtek 4-port hubs on both bus 1 and bus 2 plus my peripherals.
Since the software image, cables, and devices were all held constant and only the board changed, this points to a hardware fault on the original board rather than a software/firmware state. On the faulty board, no external port enumerates anything (lsusb shows only the root hubs and internal Bluetooth), 5V is present at the ports, and it’s dead even at the UEFI level before the OS loads.
Let me know what you need from me to move that forward. I can still capture a JP6.2.2 UART log from the faulty board if it’s required
could you move the whole SOM +NVMe from your first SOM to the 2nd SOM carrier board too?
This could fully isolate the problem.
Some software is on the QSPI of the SOM so moving NVMe is not sufficient enough.
I moved the old SOM on the new carrierboard, and the USB ports work.
Then could you also move the new SOM to the old carrier board? If this is hardware problem then we expect that would lead to failure case?
Ran the swap test both directions. Results:
- Original SOM on the new carrier board: all USB ports work normally. Both Realtek hubs enumerate, keyboard/mouse and other peripherals show up in lsusb.
- New SOM on the original carrier board: USB is dead. No external device enumerates on any Type-A port or the Type-C data port. Same signature as before — only the root hubs and internal Bluetooth appear in lsusb, and dmesg shows “usb usb2-port1: Cannot enable. Maybe the USB cable is bad?”
The fault follows the carrier board regardless of which SOM is installed, so both SOMs are good and the original carrier board is defective.
For completeness, the earlier findings still hold: USB is dead at the UEFI level on that carrier before any OS loads (a keyboard cannot navigate the UEFI menu), and it failed identically across fresh flashes of JetPack 7.2 and 6.2. The board is a genuine NVIDIA dev kit carrier on the included barrel-jack supply, and I measured 5V present at the ports.
Please do the RMA for the old carrier board.