Failed to connect Jetson Orin Nano Dev. Kit to host via USB C after flashing Jetpack 6.2

Hi there,

I used the SDK manager to flash the Jetpack 6.2 onto the Jetson Orin Nano Dev. Kit 8GB. The SDK manager is installed on Ubuntu 24.04 LTS. However, after flashing the kernel, the host computer could not detect the Jetson board when prompted to enter the Jetson’s IP, username, and password. I also tried running lsusb and sudo dmesg -w on the host computer, but there was no response.

What could be the possible cause for this issue?

Thanks.

Hi,

Could you access device through minicom or plug the monitor with your Orin Nano?
Also change other cable supporting data transfer to check whether lsusb can succeed to detect.

Thanks

Same here, I’ve been struggling for 4 days in a row to flash 6.2. Version 5.1.4 flashes well but for 6.2 it goes up to a certain point when it says it waits for the board to boot up, then times out. On the UART side, the board boots but but is not detected by sdkmanager and eventually ends up in the UEFI prompt.

Just to clarify. What we are talking about here is to dump the UART log “during the flash”.

If your flash got failed, then the system might reboot to previous stage. So if you dump log in this stage, you will just the see board is doing boot.

Also, if you want your sdkmanager to detect your Jetson, you have to put the board into recovery mode by connecting the jumper on the FRC pin.

I think I may not have described it precisely, so I’d like to clarify with more details.

The kernel image flash, including in-tree and out-of-tree modules as well as DTBs, was successfully completed using both the SDK Manager and manual build-and-flash methods. The Jetson Orin Nano Developer Kit board can now be used normally. Therefore, I don’t believe there is any issue with my USB-C cable.

In JetPack 5.x, when the USB-C cable is connected to the host computer while the board is booting normally, the host detects it as an external storage device. You can then mount the partition to access the data on the board.

In this state, the SDK Manager can be used to install additional packages such as CUDA, cuDNN, and nvidia-jetpack, but it cannot flash the kernel image since the board is not in force recovery mode. Users only need to provide the IP, username, and password of the Jetson board, and the SDK Manager will handle the installation of additional packages using apt install.

However, this does not work at all in JetPack 6.2. When the board is booted normally, the host computer cannot detect it. The board does not appear in the output of lsusb on the host, sudo dmesg -w shows no response when plugging or unplugging the board, and it is not listed under /dev/ttyUSB* or /dev/ttyACM*. Therefore, we cannot access the board via minicom, mount it to retrieve data, or install packages using the SDK Manager.

What I want to know from this forum is how to make the Jetson board’s USB-C function the same way in JetPack 6.2 as it did in JetPack 5.x.

Thanks.

Hi,

Thanks for your clarification.
We can verify the host can detect device in JP6.2 from our side.
Some questions to confirm:

  • Could you put your Orin Nano in recovery mode and detected by the host?
  • Could you execute sudo dmesg | grep usb in the Orin Nano device and share results?
  • Could you hotplug the flashing cable and check whether the new logs come to dmesg in host side?

If you want to install additional package, you could execute below commands in Orin Nano device. referred link

sudo apt update
sudo apt install nvidia-jetpack

Thanks

Then I think @ovidiu7 is not same here. @ovidiu7 please file a new topic for yourself.

@otischung0321 , please share us the dmesg on both host side and Jetson side when you reproduce this error.

Hi,

Here is the result of the testing cases

Force Recovery Mode

  1. Yes, the host successfully detected the board, and the output of lsusb is shown below:
Bus 001 Device 025: ID 0955:7523 NVIDIA Corp. APX

Note that since the board is now in force recovery mode, the SDK Manager cannot access the board via SSH and, as a result, cannot install packages, even though it can detect the board.

  1. This cannot be done in force recovery mode, so we will skip this part.

  2. Yes, when plugging the board into the host, the output of sudo dmesg -w includes:

[12538.591393] usb 1-1.1: new high-speed USB device number 36 using xhci_hcd
[12538.694485] usb 1-1.1: New USB device found, idVendor=0955, idProduct=7523, bcdDevice= 4.01
[12538.694490] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12538.694491] usb 1-1.1: Product: APX
[12538.694492] usb 1-1.1: Manufacturer: NVIDIA Corp.

When unplugging the board from the host, the output of sudo dmesg -w includes:

[12632.282282] usb 1-1.1: USB disconnect, device number 36

Normally Booting

  1. No.

  2. This is the log from sudo dmesg | grep usb on the Orin Nano device:
    usb.log (5.4 KB)

  3. No, the output of sudo dmesg -w on the host remains unchanged.

Thanks.

please share us the full dmesg. A grep with usb is not needed.

This is the log from sudo dmesg on the Jetson Orin Nano device running JetPack 6.2:
dmesg.log (58.0 KB)

Thanks.

I saw you update the Linux kernel by yourself. This is not a pure image from Jetpack/sdkmanager, right?

Yes, you can reproduce my steps using my GitHub repository.

Below are my steps:

./download_all.sh
./setup_build_env.sh
./add_exfat.sh
./modify_pinctrl.sh
./apply_dtsi_changes.sh
./compile_kernel.sh
./flash_jetson_orin_nano_nvme.sh

The reason for modifying pinctrl is explained in my previous forums post.

Note that the same issue still occurs when installing via the SDK Manager, but the logs may be different.

Thanks.

Hi,

Then could you dump your log based on pure sdkmanager result?

As David already told, we don’t see such error on our side and we are using sdkmanager image everyday.
I need your log based on this image first to make sure there is nothing broken on your board.

After this is confirmed then we can check your github steps. Is it okay for you?

Sure, I can flash another Jetson Orin Nano board using only the SDK Manager.

Additionally, this board is running JetPack 6.1, and the host can retrieve data from the board via USB-C normally when the board is booted normally. Below is the log from sudo dmesg -w on the host:

[19396.215661] usb 2-1.1: new SuperSpeed USB device number 4 using xhci_hcd
[19396.231813] usb 2-1.1: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
[19396.231816] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[19396.231816] usb 2-1.1: Product: Linux for Tegra
[19396.231817] usb 2-1.1: Manufacturer: NVIDIA
[19396.231818] usb 2-1.1: SerialNumber: 1421523024193
[19396.240480] rndis_host 2-1.1:1.0 eth0: register 'rndis_host' at usb-0000:00:14.0-1.1, RNDIS device, 4a:ba:bc:00:36:b4
[19396.242015] cdc_acm 2-1.1:1.2: ttyACM0: USB ACM device
[19396.242760] usb-storage 2-1.1:1.4: USB Mass Storage device detected
[19396.243079] scsi host8: usb-storage 2-1.1:1.4
[19396.268036] cdc_ncm 2-1.1:1.5: MAC-Address: 4a:ba:bc:00:36:b6
[19396.268154] cdc_ncm 2-1.1:1.5 eth1: register 'cdc_ncm' at usb-0000:00:14.0-1.1, CDC NCM (NO ZLP), 4a:ba:bc:00:36:b6
[19396.274148] rndis_host 2-1.1:1.0 enx4ababc0036b4: renamed from eth0
[19396.275379] cdc_ncm 2-1.1:1.5 enx4ababc0036b6: renamed from eth1
[19397.247772] scsi 8:0:0:0: Direct-Access     Linux    File-Stor Gadget 0515 PQ: 0 ANSI: 2
[19397.248050] sd 8:0:0:0: Attached scsi generic sg0 type 0
[19397.248902] sd 8:0:0:0: Power-on or device reset occurred
[19397.251287] sd 8:0:0:0: [sda] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[19397.251691] sd 8:0:0:0: [sda] Write Protect is on
[19397.251693] sd 8:0:0:0: [sda] Mode Sense: 0f 00 80 00
[19397.252090] sd 8:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[19397.263661]  sda:
[19397.263684] sd 8:0:0:0: [sda] Attached SCSI removable disk

When unplugging the board from the host, the output of sudo dmesg -w includes:

[19600.810662] usb 2-1.1: USB disconnect, device number 4
[19600.810834] rndis_host 2-1.1:1.0 enx4ababc0036b4: unregister 'rndis_host' usb-0000:00:14.0-1.1, RNDIS device
[19600.877724] cdc_ncm 2-1.1:1.5 enx4ababc0036b6: unregister 'cdc_ncm' usb-0000:00:14.0-1.1, CDC NCM (NO ZLP)

Also, the log for lsblk on the host includes:

sda           8:0    1    16M  1 disk

Please wait a moment while I flash the pure JetPack 6.2 kernel image.

Thanks.

This is the log from sudo dmesg on the Jetson Orin Nano device running “pure” JetPack 6.2:

dmesg.log (59.2 KB)

The USB-C on this board worked normally in JetPack 6.1, as I mentioned above, but does not function in JetPack 6.2.

Thanks.

Hi,

Just to clarify what I am going to do.

I would like to know if this is just usb device mode has some issue here or even whole type C port has problem.

Could you

  1. hotplug your type C cable on Jetson and see if dmesg prints out something new?
  2. could you use a type C to type A adapter on that port and connect to some simple usb devices (e.g. keyboard/mouse) and see if it could be detected?

Hi,

Here is the result of the testing:

  1. No. When I connect the board to the host computer, both instances of sudo dmesg -w remain unchanged.

  2. Yes, I connected a mouse using a Type-C to Type-A adapter, and it functioned properly.

    The output of sudo dmesg -w included:

    [58130.956153] fusb301 1-0025: fusb301_work_handler: int_sts[0x01]
    [58130.956721] fusb301 1-0025: sts[0x11], type[0x10]
    [58130.957052] fusb301 1-0025: fusb301_set_mode: mode (4)(4)
    [58130.957383] fusb301 1-0025: fusb_update_state: a
    [58131.583768] fusb301 1-0025: fusb301_set_mode: mode (1)(1)
    [58131.584107] fusb301 1-0025: fusb_update_state: b
    [58131.729754] fusb301 1-0025: fusb301_work_handler: int_sts[0x01]
    [58131.730323] fusb301 1-0025: sts[0x11], type[0x10]
    [58131.731146] fusb301 1-0025: fusb301_set_dfp_power: host current(1)
    [58131.731153] fusb301 1-0025: fusb_update_state: 7
    [58132.010676] usb 1-1: new full-speed USB device number 11 using tegra-xusb
    [58132.172261] input: ROCCAT ROCCAT Kova[+] Mouse as /devices/platform/bus@0/3610000.usb/usb1/1-
    1/1-1:1.0/0003:1E7D:2D50.000A/input/input21
    [58132.172454] input: ROCCAT ROCCAT Kova[+] Consumer Control as /devices/platform/bus@0/3610000.
    usb/usb1/1-1/1-1:1.0/0003:1E7D:2D50.000A/input/input22
    [58132.231112] hid-generic 0003:1E7D:2D50.000A: input,hidraw0: USB HID v1.10 Mouse [ROCCAT ROCCA
    T Kova[+]] on usb-3610000.usb-1/input0
    [58132.236818] input: ROCCAT ROCCAT Kova[+] as /devices/platform/bus@0/3610000.usb/usb1/1-1/1-1:
    1.1/0003:1E7D:2D50.000B/input/input24
    [58132.295445] hid-generic 0003:1E7D:2D50.000B: input,hidraw1: USB HID v1.11 Keyboard [ROCCAT RO
    CCAT Kova[+]] on usb-3610000.usb-1/input1
    [58336.961296] loop1: detected capacity change from 0 to 8
    

    When I unplugged the mouse from the board, the output of sudo dmesg -w included:

    [58367.858147] usb 1-1: USB disconnect, device number 11
    [58367.874518] fusb301 1-0025: fusb301_work_handler: int_sts[0x02]
    [58367.874529] fusb301 1-0025: fusb301_detach: type[0x10] chipstate[0x07]
    [58367.875815] fusb301 1-0025: fusb301_set_mode: mode (32)(32)
    [58367.876369] fusb301 1-0025: fusb_update_state: 1
    

    I also tried connecting a USB Type-C exFAT storage drive, and the Jetson board detected it. The output of sudo dmesg -w included:

    [58535.644410] fusb301 1-0025: fusb301_work_handler: int_sts[0x01]
    [58535.644977] fusb301 1-0025: sts[0x11], type[0x10]
    [58535.645310] fusb301 1-0025: fusb301_set_mode: mode (4)(4)
    [58535.645643] fusb301 1-0025: fusb_update_state: a
    [58536.276707] fusb301 1-0025: fusb301_set_mode: mode (1)(1)
    [58536.277044] fusb301 1-0025: fusb_update_state: b
    [58536.422463] fusb301 1-0025: fusb301_work_handler: int_sts[0x01]
    [58536.423024] fusb301 1-0025: sts[0x11], type[0x10]
    [58536.423828] fusb301 1-0025: fusb301_set_dfp_power: host current(1)
    [58536.423832] fusb301 1-0025: fusb_update_state: 7
    [58537.592021] usb 2-2: new SuperSpeed Plus Gen 2x1 USB device number 3 using tegra-xusb
    [58537.622879] usb-storage 2-2:1.0: USB Mass Storage device detected
    [58537.623644] scsi host0: usb-storage 2-2:1.0
    [58538.644463] scsi 0:0:0:0: Direct-Access     Kingston DataTraveler Max 1000 PQ: 0 ANSI: 6
    [58538.645925] sd 0:0:0:0: [sda] 2000409264 512-byte logical blocks: (1.02 TB/954 GiB)
    [58538.646041] sd 0:0:0:0: [sda] Write Protect is off
    [58538.646045] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
    [58538.646213] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [58538.650264]  sda: sda1
    [58538.720659] sd 0:0:0:0: [sda] Attached SCSI disk
    

    When I unplugged the storage device from the board, the output of sudo dmesg -w included:

    [58811.527435] fusb301 1-0025: fusb301_work_handler: int_sts[0x02]
    [58811.527446] fusb301 1-0025: fusb301_detach: type[0x10] chipstate[0x07]
    [58811.528622] fusb301 1-0025: fusb301_set_mode: mode (32)(32)
    [58811.529091] fusb301 1-0025: fusb_update_state: 1
    [58812.264675] usb 2-2: USB disconnect, device number 3
    [58812.296721] sd 0:0:0:0: [sda] Synchronizing SCSI cache
    [58812.297180] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK
    

    Note that this pure kernel image doesn’t include the exFAT kernel module and thus can’t mount the exFAT devices.

Thanks.

I switched to a simple USB-A to USB-C cable, and it worked properly. I have no idea why this happened.

This A-to-C cable came from our depth camera, and it is working fine now.

The original cable I used was a PHILIPS DLC4585C USB-C to USB-C cable. It works properly for everything except communication between the host computer and JetPack 6.2.

This is really bizarre.

So you mean if you switch the cable, then usb device mode is fine?

Yes, and I also tested this PHILIPS cable by connecting the host computer to my iPad, but it failed.

Then, I switched to the USB-A to USB-C cable, and it worked properly.

Finally, I switched the USB-A to USB-C adapter from the left one to the right one, and the PHILIPS USB-C to USB-C cable worked properly for both JetPack 6.2 and my iPad.

The only difference between these two USB-A to USB-C adapters is that the left one is USB 3.2 Gen 1, while the right one is USB 3.2 Gen 2.

I still find it bizarre that the original setup only worked properly in specific situations. Anyway, changing the USB-A to USB-C adapter solved all the problems.

I apologize for wasting your time on debugging this.