Jetson Orin Nano 8GB Developer Kit - Stuck in APX/Recovery Mode After Physical Drop, Unable to Flash

Hi everyone,

I'm looking for help with a Jetson Orin Nano 8GB Developer Kit that became unusable after a physical drop.

Background

The board was working perfectly before the incident. It was running JetPack from an NVMe SSD and had been flashed successfully multiple times in the past.

Unfortunately, while powered OFF and unplugged, the board fell from approximately desk height onto the floor.

After that incident, it stopped booting normally.

I currently do not have access to an HDMI monitor, so I cannot see any video output during boot.

Current Behavior

When power is applied:

• The power LED turns on normally.
• The cooling fan starts spinning.
• The fan then stops.
• The fan starts again.
• This cycle repeats 2-3 times.
• After that, the board never appears to boot normally.

Instead, it always appears as an APX device on the host PC:

lsusb

Output:

0955:7523 NVIDIA Corp. APX

The board remains stuck in this state.

Important Details

• Recovery jumper is NOT installed.
• NVMe SSD installed or removed makes no difference.
• Power cycles make no difference.
• The board always comes back as APX.
• This behavior started only after the physical drop.
• Before the drop the board booted and operated normally.

Host Environment

Host environment:

• Ubuntu Live USB (fresh boot sessions)
• JetPack 6.2.2
• Latest SDK Manager

I have successfully flashed this same Jetson from this same machine many times before.

SDK Manager Flash Failure

SDK Manager detects the board correctly.

Flashing starts but consistently fails during blob transfer.

Relevant log:

BL: version 1.4.0.7-t234-54845784-56c609fa
last_boot_error: 0

Sending bct_mem
Sending blob

ERROR: might be timeout in USB write.
Error: Return value 3

Full failure section:

Sending bct_mem
Sending blob

ERROR: might be timeout in USB write.
Error: Return value 3

Command tegrarcm_v2 --instance 3-1 --chip 0x23 0 --pollbl --download bct_mem mem_rcm_sigheader.bct.encrypt --download blob blob.bin

USB Behavior During Flashing

While monitoring:

dmesg -w

I repeatedly see:

usb 3-1: USB disconnect
usb 3-1: new high-speed USB device
Product: APX
Manufacturer: NVIDIA Corp.

The board disconnects and reconnects as APX.

I do NOT see errors such as:

device descriptor read error
unable to enumerate
USB reset failed

Only disconnect/reconnect events.

Previous Flash Attempts Reached 99%

Before rebuilding everything from scratch, I occasionally had a different failure mode.

Some flashing attempts reached approximately 99% completion before failing or hanging.

Example messages included:

clnt_create: RPC: Timed out
NFS server is not running

or the flashing process would simply stall at 99%.

After recreating the flashing environment from scratch, the failure now occurs earlier during blob transfer.

Manual Flash Attempt

I also tried flashing manually from the command line instead of SDK Manager.

The flash package builds successfully, but the process later fails with:

Stat for blob_boot0.imgimg failed
Error: Return value 19

The generated command contains:

kernel boot0.imgimg

instead of:

kernel boot0.img

which looks suspicious.

Relevant output:

Generating blob for T23x

tegrahost_v2 --chip 0x23 0 --generateblob blob.xml blob.bin

Stat for blob_boot0.imgimg failed

Error: Return value 19

EEPROM Information

During flashing the board EEPROM is successfully read.

Detected information includes:

Board ID: 3767
Board SKU: 0005
Board Revision: T.1

SDK Manager identifies the target as:

jetson-orin-nano-devkit-super

even though I believe this is a standard Jetson Orin Nano 8GB Developer Kit.

I'm not sure whether that is expected or related to the issue.

What I Have Already Tried

• Rebooting and power cycling.
• Removing the recovery jumper.
• Flashing with NVMe SSD installed.
• Flashing with NVMe SSD removed.
• Reinstalling and reseating the SSD.
• Fresh Ubuntu Live USB sessions.
• Rebuilding Linux_for_Tegra.
• Re-downloading JetPack files.
• Using SDK Manager.
• Using command-line flashing tools.
• Recreating the entire flashing environment from scratch.

None of these changed the behavior.

Questions

1. Could the physical drop have damaged something that still allows APX mode but causes blob transfer failures?
2. Can corrupted QSPI firmware cause a board to remain permanently in APX mode even without the recovery jumper installed?
3. Has anyone seen repeated APX disconnect/reconnect behavior during flashing like this?
4. Has anyone encountered the boot0.imgimg issue before?
5. Is there a recommended way to completely recover or reinitialize QSPI from APX mode?
6. Does this look more like a software issue or a hardware failure caused by the drop?

Thank you.