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?
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”?
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.
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?
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 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.