[SDK Manager CLI] 'Could not detect correct NVIDIA Jetson device connected to USB.'


This is the third post for troubleshooting Jetson flashing process. You can check other posts made by me. It would be good if these additional posts helps you to draw clearer picture of my situation.
(SD Card Image Method)
L4TLauncher: Attempting Direct Boot (Jetson Nano Orin Dev kit)
(SDK Manager GUI Method)
JetPack 5.1.1 Installation Failed with SDK Manager (Jetson Orin Nano Dev Kit)

Hello,

While I’m trying to flash Jetson Orin Nano 8GB Dev Kit with JetPack 5.1.1 using SDK Manager CLI, I encountered a not understandable error.

I followed the official document which explains how to use SDK Manager CLI.
https://docs.nvidia.com/sdk-manager/sdkm-command-line-install/index.html

The necessary components for Host and Target were automatically downloaded.
Made Jetson be in Force Recovery Mode and connected with Host PC.
And I when through several steps like choosing one between several options.

But in the end, an error came up.
error: Could not detect correct NVIDIA Jetson device connected to USB.

But when I checked the connection by running ‘lsusb’ command, it shows the Jetson is well connected to the Host. (‘Bus 001 Device 025: ID 0955:7523 NVIDIA Corp. APX’)

I’m so confusing whether the Host and Target are really connected well or not.

I’m not positive, but the more recent L4T R35.3.1 might be required for the Orin Nano. More importantly though, if it says APX, it makes me think this is a VM and not native Linux. VMs are notorious for not correctly passing through USB. Even in cases where a VM starts correctly, USB disconnects and reconnects during the flash, and VMs tend to lose USB then as well.

So I suggest first switching to the newer JetPack (which is the installer’s GUI front end…L4T is what actually gets flashed). If there is any way to avoid a VM, I would recommend doing so with a native Ubuntu 20.04 host PC. If not, then you may have to talk to the VM vendor about making sure USB remains at all times such that it survives disconnect and reconnect.

Thanks for your comment.
Actually, I was using Ubuntu 20.04 PC as a host. So I thought my problem is not caused by the usage of VM.
(btw, what exactly is VM? Does VM mean the sub-environment of Ubuntu that run on another real host like Windows or MacOS(like the picture below)? It’s possible that I might misunderstood what is VM and what is not VM.)

A VM is a Virtual Machine. If you have a host running something like Windows, or a different distribution of Linux, or a Mac, then you can create a kind of “container” environment, and the VM acts like a completely blank environment (separated from the original host) such that you could install another operating system without interfering with the original system. Windows Subsystem for Linux (WSL and WSL2) are examples. Other examples are VMware, VirtualBox, and KVM.

Normally a VM (any brand) has to have any devices it sees passed through by configuration of the VM from the original host. So if you run a VM in either Windows or Linux, and you install a new operating system in the VM, then the VM won’t see the mouse or keyboard unless you configure to pass those through to the VM’s hosted system. For USB, the APX is a very strong hint that a VM is involved.

USB passthrough instructions differ for every VM. Whatever runs inside the VM (such as JetPack or flash software or Ubuntu itself) has no knowledge or control over what the host/parent o/s allows passing through.

VMware is one of those. It is a good VM, but without finding out how to properly pass through this “custom” USB situation, it will fail. VMware would be able to tell you how to pass through some particular USB ID (it is a manufacturer ID plus a device ID) such that it stays connected no matter how often it disconnects or reconnects. This is very very likely the problem.

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