Nvidia Xavier NX Black screen

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi,
I currently have a Jetson Xavier NX which shows a black screen (no display with HDMI recognized), though the light goes on when the Jetson is powered.
I would like to do a complete reset of the system. How to do this ? I am using my PC, a Windows 11 computer. I am a beginner here, sorry… Let me know what I can do to give more info. Thans a lot!

2

I will suggest you need to flash with the most recent L4T R35.x (L4T is just Ubuntu plus NVIDIA drivers; this is what gets flashed). JetPack/SDK Manager is what is normally used to perform the flash. See:
https://developer.nvidia.com/linux-tegra

Flash is performed in recovery mode. This turns the Jetson into a custom USB device, and is only understood by the custom USB driver. This happens to be what the flash software is in the lower layers. JetPack/SDK Manager are just front ends to the command line flash. You will not find this easy because the driver package (the part that actually flashes the Jetson) is a Linux architecture (desktop PC) binary executable file. This cannot run on Windows.

During flash there are also other features of Linux which Windows does not have, and so there is far more to flashing than just running the flash software on an emulation.

I will tell you right now your easiest and least problematic path is to add a second hard drive onto your computer and dual boot to the second drive. You’d want to use Ubuntu 20.04.

Barring that, I will tell you about some unsupported methods.

A VM can be made to work, but this tends to require some expertise about the VM (it isn’t the flash software that has control over this). Any flash from a VM requires:

  • An ext4 filesystem underneath it (no Windows filesystem can succeed; the flash would appear to work, but mostly the Jetson would not work).
  • Support for loopback. Many VMs have this, but for the Windows WSL, only WSL2 has loopback. You would need to be absolutely certain that loopback is supported in your Ubuntu 20.04 VM.
  • USB will disconnect and reconnect during flash. Many VMs are configured incorrectly and fail to reacquire USB after the reconnect.
  • A large amount of disk space. The entire root filesystem partition is generated, and then a subset with just the content of the rootfs is generated. If your partition is 32 GB, and if it is half filled, then this consumes 32+16=48 GB just to start before even including the operating system or flash software.

If you have an Ubuntu 20.04 installation, then you could just install sdkmanager (which is paired with JetPack…sdkm is the smart network layer), and when you run it, everything for flash and development would be installed. You could simply put the Jetson in recovery mode, attach it via the correct USB port, and flash. There are other advantages to developing natively under Linux if you are interested in CUDA or AI.

Documentation is paired with the particular L4T release. See the above URL and look for docs there for the most recent L4T R35.x release. If you want to test JetPack on a VM, then this too is there.

3

Thank you very much for your detailed answer. I ended up borrowing a Linux Ubuntu 20.04 device and installing SDKmanager on it. I connected my Jetson to power, put my Jetson device in recovery mode (jumper between FC REC and GND i.e. 9 and 10) and performed the flash. However, I got the following error :

The target is in a bad state

The Jetson target is in a bad state and cannot be flashed. Please manually put the target into recovery mode and then retry flashing

Attached is the log.
SDKM_logs_JetPack_5.1.3_Linux_for_Jetson_Xavier_NX_modules_2024-06-25_11-41-42.zip (649.5 KB)
What should I do ?
Thank you very much for your help!!

4

Is this an SD card model without eMMC, or does this have eMMC? What cable did you use? Cable quality matters a lot since “charger” cables usually don’t work well with data (I’d say two out of three brands of charger cables will fail).

Incidentally, you only need to short the recovery pin to ground (pins 9 and 10 under the module count for this; the 40-pin headers are incorrect) during either (A) power on or (B) power reset. There is no need to maintain the recovery pin grounding after those events (think of it as a SHIFT key on a keyboard for getting capital letters).

Also, on the host PC, do you see anything with recovery mode active from “lsusb -d '0955:'”?

5

Thank you so much for your answer, I believe the cable was the problem ! :) It all worked out.

6

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