Jetson Orin NX won't enter recovery mode

My Jetson Orin NX will no longer enter force recovery mode. I was able to flash it last week but can no longer do so. It always boots into the OS.

I have tried:
* sudo reboot --force forced-recovery from the OS.

  • connecting pins 9 and 10 on the header to enter force recovery, and then plugging in power.

In each case it just reboots into the OS. SDKmanager can’t find the board and I can’t see it through lsusb.

Is there anything else I should try or should I ask for an RMA?

*** Please note that this reply is generated by LLM automatically ***

To troubleshoot the issue with your Jetson Orin NX not entering Force Recovery Mode, let’s go through the steps you’ve already tried and some additional ones.

Steps you’ve already tried:

  1. Connecting pins 9 and 10 on the header to enter Force Recovery Mode and then plugging in power.
  2. Using SDK Manager to find the board, but it’s not visible.

Additional steps to try:

  1. Verify the header pins: Double-check that you’re connecting the correct pins (9 and 10) on the header. Make sure they’re securely connected and not loose.
  2. Use a different USB port: Try using a different USB port on your host computer to connect to the Jetson Orin NX. This will help rule out any issues with the USB port.
  3. Check the USB cable: Ensure that the USB cable is not damaged and is securely connected to both the Jetson Orin NX and the host computer.
  4. Power cycle the board: Try power cycling the Jetson Orin NX by unplugging the power cord, waiting for 10 seconds, and then plugging it back in.
  5. Use the lsusb command: Open a terminal window on your host computer and run the lsusb command. This will list all the USB devices connected to your computer. Look for the Jetson Orin NX device (it should be listed as “Nvidia Corp.” with a specific ID, e.g., “0955:7423”). If you don’t see the device listed, it may indicate a hardware issue.
  6. Try a different host computer: If possible, try connecting the Jetson Orin NX to a different host computer to rule out any issues with the current host computer.
  7. Check the Jetson Orin NX documentation: Review the Jetson Orin NX documentation to ensure you’re following the correct procedure for entering Force Recovery Mode.

Comparison with other Jetson modules:

The procedure for entering Force Recovery Mode is similar across different Jetson modules. However, the specific pins used to enter Force Recovery Mode may vary depending on the module. For example, on the Jetson AGX Orin, pins 9 and 10 are used, while on the Jetson Xavier NX, pins 10 and 11 are used.

RMA (Return Merchandise Authorization) consideration:

If none of the above steps resolve the issue, it’s possible that there’s a hardware problem with the Jetson Orin NX. In this case, you may need to contact NVIDIA support to request an RMA. Before doing so, make sure you’ve tried all the troubleshooting steps above and have documented the issue thoroughly.

In summary, try the additional steps outlined above to troubleshoot the issue with your Jetson Orin NX not entering Force Recovery Mode. If none of these steps resolve the issue, it may be necessary to contact NVIDIA support for further assistance or to request an RMA.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

  1. I’ve verified I’m using the correct header pins.
    2. I’ve tried different USB ports without success. Using the same host PC I can connect to another Orin and see that it’s in recovery mode, but not the device in question.
    3. I’ve tried power cycles without success
    4. The board does not show up on lsusb.
    7. I’ve followed the steps here : Jetson Orin Nano Developer Kit User Guide - How-to | NVIDIA Developer

    Again, this board was working last week, now it’s not. With a different Orin board, I can put it into recovery mode and see it in lsusb and sdkmanager. With this board I can’t - I think this is a hardware issue.

Hi @c.blair

Could you confirm the JetPack/L4T version, the exact Orin NX SKU, and the carrier board you are using?

Since the same host PC can detect another Orin in recovery mode, this does not look like a typical SDK Manager or host-side USB issue. The next useful step is to isolate whether the failure follows the module or the carrier board.

Please try one of the following cross-checks:

  1. Test this Orin NX module on a known-good carrier

    Install the suspect Orin NX module on a known-good NVIDIA Orin Nano devkit carrier, then try Force Recovery Mode again.

  2. Test a known-good module on this carrier

    Install a known-good Orin NX/Nano module on this carrier and check whether it can enter Force Recovery Mode.

When the module is in Force Recovery Mode, the host should show an NVIDIA USB device in lsusb, for example:

ID 0955:7323 Nvidia Corp.  # Jetson Orin NX 16GB
ID 0955:7423 Nvidia Corp.  # Jetson Orin NX 8GB

Recommendation:
If this same Orin NX module still cannot enter Force Recovery Mode on a known-good carrier, while another module works with the same host/cable/procedure, then it is reasonable to proceed with the RMA path.

For reference, the Orin Nano Developer Kit guide documents Force Recovery Mode using the button-header REC/GND pins, and the Jetson Linux guide documents the expected lsusb IDs for Orin NX recovery mode:

Hope this helps!

Hi @wichiu

I’m using Jetpack 6.2.1, a Jetson Orin NX P3767, and the Jetson Orin Nano developer board P3766.

This is cross-check 2:

On the P3767 carrier board, the NX boots into the normal OS when the FC REC pin is grounded. It does not show up on lsusb.

When I connected a known-good Orin Nano to this carrier board when the FC REC pin is grounded, it appears on lsusb as 0955:7523 (i.e. recovery mode) which is what I’d expect. So the fault is with the Orin NX SOC, not the carrier board. Can I proceed with an RMA please?

Hi @c.blair,

Before we decide the next step, could you please capture the host-side USB messages with the following command?

sudo dmesg -w

While this command is running on the host PC, please:

  1. Disconnect and reconnect the USB cable between the host and the Jetson carrier board.
  2. Power-cycle the board with FC REC asserted.
  3. Copy the new dmesg messages that appear during that test.

If Force Recovery Mode is even partially working, the host may show USB messages such as a new USB device, reset/disconnect events, enumeration failures, or USB driver/port errors.

Also, one terminology clarification, just to make sure we are referring to the same hardware:

  • P3767 is the Jetson Orin NX / Orin Nano module, also called the SOM.
  • P3768 is the Jetson Orin Nano developer kit carrier board.
  • P3766 refers to the complete Jetson Orin Nano developer kit assembly.
  • The Orin SoC itself is on the P3767 module and is not a separately replaceable part in this context.

So I currently understand your test result as:

  1. Suspect Orin NX module

    Suspect Orin NX P3767 module + the same Orin Nano developer kit carrier board:

    • FC REC asserted
    • The board still boots into the normal OS
    • No NVIDIA recovery device appears in lsusb
  2. Known-good Orin Nano module

    Known-good Orin Nano module + the same carrier board / host / cable / procedure:

    • FC REC asserted
    • The host sees 0955:7523, which means the module entered Force Recovery Mode

Please confirm whether the above hardware mapping is correct.

Recommendation:
I need the complete test information above, especially the host-side dmesg output and confirmation of the module/carrier combinations, before I can recommend proceeding with the RMA path.

Thanks.

Hi @wichiu the above hardware mapping - 1 and 2 - is correct.

dmesg output:

  1. plug in USB cable and turn on power with FC REC asserted:

[84918.894925] usb 2-2-port2: config error
[84962.316031] usb 2-2.2: new SuperSpeed USB device number 21 using xhci_hcd
[84962.328037] usb 2-2.2: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
[84962.328045] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[84962.328048] usb 2-2.2: Product: Linux for Tegra
[84962.328050] usb 2-2.2: Manufacturer: NVIDIA
[84962.328052] usb 2-2.2: SerialNumber: 1420723036241
[84962.333211] rndis_host 2-2.2:1.0 usb0: register ‘rndis_host’ at usb-0000:00:0d.0-2.2, RNDIS device, 46:18:27:37:57:a8
[84962.335813] cdc_acm 2-2.2:1.2: ttyACM0: USB ACM device
[84962.337837] usb-storage 2-2.2:1.4: USB Mass Storage device detected
[84962.338098] scsi host1: usb-storage 2-2.2:1.4
[84962.361164] cdc_ncm 2-2.2:1.5: MAC-Address: 46:18:27:37:57:aa
[84962.361808] cdc_ncm 2-2.2:1.5 usb1: register ‘cdc_ncm’ at usb-0000:00:0d.0-2.2, CDC NCM (NO ZLP), 46:18:27:37:57:aa
[84962.382152] rndis_host 2-2.2:1.0 enx4618273757a8: renamed from usb0
[84962.383806] cdc_ncm 2-2.2:1.5 enx4618273757aa: renamed from usb1
[84963.342289] scsi 1:0:0:0: Direct-Access Linux File-Stor Gadget 0515 PQ: 0 ANSI: 2
[84963.343345] sd 1:0:0:0: Attached scsi generic sg2 type 0
[84963.344142] sd 1:0:0:0: Power-on or device reset occurred
[84963.345278] sd 1:0:0:0: [sdc] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[84963.345453] sd 1:0:0:0: [sdc] Write Protect is on
[84963.345461] sd 1:0:0:0: [sdc] Mode Sense: 0f 00 80 00
[84963.345600] sd 1:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
[84963.384563] sdc:
[84963.384593] sd 1:0:0:0: [sdc] Attached SCSI removable disk

lsusb now shows:

$ lsusb -d 0955:
Bus 002 Device 021: ID 0955:7020 NVIDIA Corp. L4T (Linux for Tegra) running on Tegra

i.e. not recovery mode.

  1. Disconnect and reconnect usb cable:
[85163.917603] usb 2-2.2: USB disconnect, device number 21
[85163.917751] rndis_host 2-2.2:1.0 enx4618273757a8: unregister 'rndis_host' usb-0000:00:0d.0-2.2, RNDIS device
[85163.996900] cdc_ncm 2-2.2:1.5 enx4618273757aa: unregister 'cdc_ncm' usb-0000:00:0d.0-2.2, CDC NCM (NO ZLP)
[85169.002728] usb 2-2.2: new SuperSpeed USB device number 22 using xhci_hcd
[85169.015985] usb 2-2.2: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
[85169.015989] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[85169.015991] usb 2-2.2: Product: Linux for Tegra
[85169.015992] usb 2-2.2: Manufacturer: NVIDIA
[85169.015992] usb 2-2.2: SerialNumber: 1420723036241
[85169.020296] rndis_host 2-2.2:1.0 usb0: register 'rndis_host' at usb-0000:00:0d.0-2.2, RNDIS device, 46:18:27:37:57:a8
[85169.022302] cdc_acm 2-2.2:1.2: ttyACM0: USB ACM device
[85169.024934] usb-storage 2-2.2:1.4: USB Mass Storage device detected
[85169.025260] scsi host1: usb-storage 2-2.2:1.4
[85169.047235] cdc_ncm 2-2.2:1.5: MAC-Address: 46:18:27:37:57:aa
[85169.047435] cdc_ncm 2-2.2:1.5 usb1: register 'cdc_ncm' at usb-0000:00:0d.0-2.2, CDC NCM (NO ZLP), 46:18:27:37:57:aa
[85169.058315] cdc_ncm 2-2.2:1.5 enx4618273757aa: renamed from usb1
[85169.059241] rndis_host 2-2.2:1.0 enx4618273757a8: renamed from usb0
[85170.068003] scsi 1:0:0:0: Direct-Access     Linux    File-Stor Gadget 0515 PQ: 0 ANSI: 2
[85170.068982] sd 1:0:0:0: Attached scsi generic sg2 type 0
[85170.069285] sd 1:0:0:0: Power-on or device reset occurred
[85170.070444] sd 1:0:0:0: [sdc] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[85170.070684] sd 1:0:0:0: [sdc] Write Protect is on
[85170.070713] sd 1:0:0:0: [sdc] Mode Sense: 0f 00 80 00
[85170.070907] sd 1:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[85170.108546]  sdc:
[85170.108571] sd 1:0:0:0: [sdc] Attached SCSI removable disk

  1. Power cycle with FC REC asserted:
[85214.557940] usb 2-2.2: USB disconnect, device number 22
[85214.558192] rndis_host 2-2.2:1.0 enx4618273757a8: unregister 'rndis_host' usb-0000:00:0d.0-2.2, RNDIS device
[85214.623982] cdc_ncm 2-2.2:1.5 enx4618273757aa: unregister 'cdc_ncm' usb-0000:00:0d.0-2.2, CDC NCM (NO ZLP)
[85271.054724] usb 2-2-port2: config error
[85313.165330] usb 2-2.2: new SuperSpeed USB device number 23 using xhci_hcd
[85313.177100] usb 2-2.2: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
[85313.177109] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[85313.177112] usb 2-2.2: Product: Linux for Tegra
[85313.177115] usb 2-2.2: Manufacturer: NVIDIA
[85313.177117] usb 2-2.2: SerialNumber: 1420723036241
[85313.182190] rndis_host 2-2.2:1.0 usb0: register 'rndis_host' at usb-0000:00:0d.0-2.2, RNDIS device, 46:18:27:37:57:a8
[85313.184524] cdc_acm 2-2.2:1.2: ttyACM0: USB ACM device
[85313.185613] usb-storage 2-2.2:1.4: USB Mass Storage device detected
[85313.185871] scsi host1: usb-storage 2-2.2:1.4
[85313.208086] cdc_ncm 2-2.2:1.5: MAC-Address: 46:18:27:37:57:aa
[85313.208952] cdc_ncm 2-2.2:1.5 usb1: register 'cdc_ncm' at usb-0000:00:0d.0-2.2, CDC NCM (NO ZLP), 46:18:27:37:57:aa
[85313.231037] rndis_host 2-2.2:1.0 enx4618273757a8: renamed from usb0
[85313.234759] cdc_ncm 2-2.2:1.5 enx4618273757aa: renamed from usb1
[85314.199721] scsi 1:0:0:0: Direct-Access     Linux    File-Stor Gadget 0515 PQ: 0 ANSI: 2
[85314.200392] sd 1:0:0:0: Attached scsi generic sg2 type 0
[85314.200810] sd 1:0:0:0: Power-on or device reset occurred
[85314.201555] sd 1:0:0:0: [sdc] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[85314.201793] sd 1:0:0:0: [sdc] Write Protect is on
[85314.201801] sd 1:0:0:0: [sdc] Mode Sense: 0f 00 80 00
[85314.201927] sd 1:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[85314.224645]  sdc:
[85314.224673] sd 1:0:0:0: [sdc] Attached SCSI removable disk

and again lsusb shows

$ lsusb -d 0955:
Bus 002 Device 023: ID 0955:7020 NVIDIA Corp. L4T (Linux for Tegra) running on Tegra

so the NX is not in recovery mode.

Hi @c.blair,

Your latest test confirms that the suspect Orin NX module is not entering Force Recovery Mode.

With FC REC asserted, it still enumerates as normal L4T:

0955:7020 NVIDIA Corp. L4T (Linux for Tegra) running on Tegra

An Orin NX in Force Recovery Mode should appear as 0955:7323 or 0955:7423. Since a known-good Orin Nano enters Force Recovery Mode as 0955:7523 using the same carrier board / host / cable / procedure, the issue follows the suspect Orin NX module.

Recommendation:
Please proceed with RMA for the suspect Orin NX P3767 module/SOM through the Jetson RMA process:

Please include the dmesg / lsusb results from this thread in the RMA request.

Thanks.