Flash failure on Jetson Orin NX

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

I’m working with a Jetson Orin NX 8 GB and encountering a serious issue during flashing. The board unexpectedly powers off during the flashing process using l4t_initrd_flash.sh, and the process never completes.
what I’ve tried so far:

  1. Switched USB cables ✅
  2. Switched power supply (using a reliable 5V/4A adapter) ✅
  3. Replaced the Jetson module itself ✅
  4. Host OS: Ubuntu 24.04 LTS ✅
  5. Verified that system.img begins writing, but Jetson shuts down or hangs before completion ❌

Observed Behavior:

  • The process proceeds through GPT creation and partition writing on the NVMe SSD.
  • When it reaches the rootfs (system.img) writing stage, the Jetson powers off suddenly.
  • A message appears in logs:
Please install the Secureboot package to use initrd flash for fused board

However, there is no evidence that the board is fused, and this message may be misleading.

  • There is no sign of undervoltage or overheating.
  • The issue is consistent across multiple Jetson modules

the flash command:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network usb0 jetson-orin-nano-devkit-super internal | tee flash.log
the flash log file attached.

flash.log (282.6 KB)

please help.

3

The true flash error is this one.

Either the device cannot mount the NFS server on the host or a flash command has failed. Check your network setting (VPN, firewall,…) to make sure the device can mount NFS server. Debug log saved to /tmp/tmp.lDLoE7LOQj. You can access the target’s terminal through "sshpass -p root ssh root@fc00:1:1:0::2

Check if you have ufw enabled. If there is, please disable it an try again.

4

Thanks for your reply.
I just wanted to clarify that the error message about NFS or SSH appears after the Jetson board suddenly powers off during flashing.

In other words, the board shuts down midway through the flashing process, always at the same point, and that’s when the host throws the NFS/SSH error — likely because the device is no longer online at that point.

So I don’t think the root cause is a network or firewall issue. The real problem seems to be that the board is shutting down unexpectedly, and the host simply can’t connect to it anymore afterward.

5

Hi,

How did you tell the board is powered off? Are you using any log /serial console to check? or you directly saw the power LED is gone?

6

Hi. thanks for your reply.

Yes, I can confirm that the power LED on the board turns off completely during flashing — the board loses power, and it’s no longer detected via USB on the host machine.

This happens consistently at the exact same stage of the flashing process, even after multiple attempts.

I’ve repeated the process many times and also tried:

  • Different USB cables
  • Different power supplies (using a reliable 5V/4A source)
  • Replacing the Jetson module
  • Using a high-quality NVMe SSD (SK Hynix)

So far, the behavior is always the same — shutdown at the same point.

🧠 I’m wondering:

  1. Could this be caused by the board overheating?
    I haven’t attached a heatsink or fan yet — could temperature trigger a thermal shutdown during flashing?
  2. Could the SSD still be the cause?
    Even though I’m using a well-known compatible SSD, is it possible that a driver or power draw issue is triggering a failure?
  3. Is there any other indication in my flash log that suggests what’s really going wrong?
7

I checked ufw. It was inactive.

8

Just to clarify. Is this a NV devkit or custom board?

9

custom board.

10

Then it could be thermal problem. Please enhance that part first.

11

Thanks for confirming that it could be a thermal issue — I’m working on adding proper cooling (heatsink + fan) before retrying the flash.

In the meantime, I wanted to ask:
Would it be possible for you (or someone from the team) to please take a look at my full flash log and let me know if there are any other errors or warnings that might indicate another underlying issue?

I want to make sure:

  • All GPT/partitioning steps are completing correctly
  • The QSPI flash stage is being done properly
  • There’s no missing image, config file, or version mismatch
  • And that the shutdown is truly the only point of failure

📎 (Log was previously attached here, but I can re-upload if needed.)

Let me know if I should collect UART logs as well.

Thanks again for the support.

12

Hi,

You should collect UART too.

13

I used heatsink. the flash complete successfully but, now when I boot the board:

  • I see the NVIDIA logo for a second
  • Then it quickly moves to a black screen with a blinking cursor (no login prompt, no GUI)
  • Sometimes it briefly shows an error about failing to mount something, but I can’t read it in time
  • After that, it stays stuck on the black screen

I already tried:

✔ Editing the extlinux.conf and setting:
APPEND root=/dev/nvme0n1p1 rw rootwait quie

14

You should collect UART log. That is far more helpful than your current comment.

15

I tried capturing UART logs from my Jetson Orin NX (Seeed Studio A603 carrier board) using a USB-to-UART cable.

I connected:

  • TX → Pin 10 (RX on Jetson)
  • RX → Pin 8 (TX on Jetson)
  • GND → Pin 6

I used minicom at 115200 baud and confirmed that /dev/ttyUSB0 is detected. However, I’m not getting any output at all during boot — the log file remains completely empty.

I also double-checked the connections and reversed TX/RX just in case, but still no result.

Now I’m starting to think that the A603 board may not expose UART on the default GPIO header (Pins 8/10), or that it uses a dedicated debug UART elsewhere on the board (e.g. a separate connector or USB-C debug).

I couldn’t find more info in the documentation, so:

🔹 Could you please confirm if UART output is supported on the GPIO header for this board?

🔹 And if not, is there another way to capture early boot logs or understand what’s causing the system to stall at boot (black screen after NVIDIA logo)?

Any alternative debug method would be appreciated

Thanks in advance.

16

Hi,

As that is a custom board, please check the website of the vendor to see how to dump log on their board. We won’t know.

17

the problem solved by reflashing.
thanks alot.

19

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