Jetson Nano USB Type A Ports not working


I was using the USB ports of Jetson Nano to connect Bluetooth Keyboard and mouse, and to control motor drivers via micro-USB cables. I have also connected a HDMI display.

All ports have been working fine for over six months. But, suddenly, none of the USB ports are working, (devices connected to it are not responding, but work fine when connected to my PC).
No configuration was changed, the board boots up as normal but I can access it only via the Micro USB serial terminal or the ethernet port.

Any ideas on what might have gone wrong? I went through other posts in the forum and most conclude that the board is damaged. How do I debug this?

There is a chance of damage. To debug you would need a serial console boot log. See:

Serial console programs can log everything, and you’d need to start logging just prior to booting up. Serial console will survive a lot of failures.

The log is attached here. It doesn’t show any USB failure to my knowledge. I didn’t connect a display and that is reflected in the log.
nano_usbissue.log (20.4 KB)

I don’t see anything particularly useful in that log. If you have the serial console running “dmesg --follow”, and you then insert a USB device, e.g., a keyboard, into USB, what log lines show up as a result of that plug-in?

Also, with something USB plugged in, what do you see from “lsusb -t -v”?

With the USB mouse plugged in,

user@bauv:~$ lsusb -t -v
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M

The dmesg --follow keeps printing configfs-gadget gadget: Wrong NDP SIGN. There is no change when the USB device is connected. The full log is attached.

nano_dmesg.txt (99.5 KB)

From what I can tell the root HUBs are not talking to the physical interface.

Regarding configfs-gadget, this is the virtual wired network device and the example USB mass storage device. Those apply only to the micro-USB port, and this port can only be in device mode (the other ports are host mode).

Hardware failure could cause this, but higher on the list is the wrong firmware. Is this a developer’s kit? Or is this a module on a third party carrier board?

No, this is a kit from Nvidia procured last year.

It was working fine since then before the issue. If hardware failure is the issue, can you help me with the possible cause so that I may avoid it in the future?

Do you have any valuable content on this? If so, then you could first clone, but the next step would be flash of the module itself (a QSPI flash using a release compatible with your SD card), and/or trying a new SD card. It might be nothing more than some sort of storage media failure/corruption. Knowing why this occurred would probably require seeing the logs which occurred while the error first occurred. Let me know if you want information on cloning either an SD card or an eMMC model of Jetson (but if it is the SD card which is bad, then you probably want to try a new SD card anyway).

I will flash a new card and try. I’m able to access the data via ethernet, so I can take a backup of the same.

I recommend rsync over ssh if you are performing remote backup. It is actually a good idea to set up a script to do this since incremental backups via rsync take less time.

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