I following the instructions here (Jetson Orin Nano Developer Kit Getting Started Guide | NVIDIA Developer) to setup the Jetson Orin Nano devkit.
The power LED goes on, but the display stays blank. Any idea why this would happen?
I saw a couple of other posts that recommend flashing it from a host. Do you suggest this? If so, could you please point to the links to put the device into recovery mode and flash it from a host?
Orin Nanos have their rootfs (o/s) on the SD card. They also have QSPI memory on the module itself. The QSPI contains the boot content, and has a lot to do with whether or not a given L4T release (which is what gets flashed, it’s Ubuntu plus NVIDIA drivers) on the SD card will boot correctly.
Also, what is your actual monitor wiring? If it uses a VGA adapter and is not natively either HDMI or DisplayPort, then I’d expect video to fail (although the Jetson would be fully booted and you’d just not know it).
The number one tool, if flash of QSPI fails, is serial console. You can get a serial console log, and attach that to the forums. That requires a TTL (3.3V) serial UART USB cable (they’re usually not too expensive, and are quite valuable for working on anything embedded).
Thanks for your detailed answer, this is very helpful.
The monitor did have a DP port, so I did not use an adapter.
I couldn’t find a USB to TTL cable, so I used a USB-C to A cable to connect the Orin Nano to a Linux host and shorted the GND and FRC RST pins to get the serial log.
While I see the device listed as a USB device, I don’t see a corresponding tty device created. Any idea what might be wrong? I tried a different cable, different port on the host etc.
lsusb output
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 017: ID 0955:7523 NVIDIA Corp. APX
Bus 001 Device 004: ID 413c:2113 Dell Computer Corp. KB216 Wired Keyboard
dmesg output
[ 1710.850213] usb 1-8: new high-speed USB device number 17 using xhci_hcd
[ 1710.999588] usb 1-8: New USB device found, idVendor=0955, idProduct=7523, bcdDevice= 4.01
[ 1710.999600] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1710.999606] usb 1-8: Product: APX
[ 1710.999610] usb 1-8: Manufacturer: NVIDIA Corp.
I tried a different host and was able to see a ttyUSB0. However, minicom does not show any logs upon reboot.
I also noticed that when the DC power supply is removed from the Nano, the USB device doesn’t show up. I checked that I am using a USB cable with data and power. Am I missing something here?
You’d want to get the serial console log from a normal boot without recovery mode. You should be able to get some debug information if you start logging serial console prior to applying power to the Orin Nano. It is useful to see serial console log during flash itself whenever flash is failing, but just seeing what goes on during normal boot is where you would start. Also, if the system is just failing at graphics the serial console would allow first boot setup and logging in to access on command line (which in turn would offer the GUI log).
I should not have mentioned the TTL cable, which is still useful with the serial UART on the header, but if the USB-C has serial console (I don’t know for sure if it is that or the pins 8 and 10 which have this), then you wouldn’t need the TTL cable (I don’t have an Orin Nano to look at).
Now something which does look wrong is on the lsusb output I see this:
Bus 001 Device 017: ID 0955:7523 NVIDIA Corp. APX
The “APX” usually shows up with a VM. If the host PC is a VM, then I’d expect flash failure, and although it could work well for serial console or other purposes, a VM often has incorrect default USB setup which will cause USB to fail. Make sure to always use a native Ubuntu (18.04 or 20.04 will work, 20.04 being preferable).
I’m going to suggest checking serial console again during boot (not recovery mode), but check with gtkterm. You’ll probably need to “sudo apt-get install gtkterm”. Since the port is ttyUSB0, this should work:
sudo gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0
If you get no log from that, it is time to use JetPack/SDK Manager to flash the QSPI memory on the Nano module. You’d want to use the most recent release (L4T release and JetPack releases are tied together, so if you pick one or the other it leads to the same thing). You can find the releases here:
Note for NVIDIA: I don’t see the Orin Nano listed in in the L4T listing, but I do see it in the JetPack 5.1.1 listing. Probably the L4T release page needs to have the Orin Nano added.
For reference, Jetpack 5.1.1 matches L4T R35.3.1 and shows it works with Orin Nano.
I want to emphasize that although a VM can work, VMs often fail because they need the USB properly configured to keep the USB even when it disconnects and reconnects. WSL2 is particularly problematic because, if an image is being created, it needs loopback to be added. If you see APX you should suspect a VM.
Thank you!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.