Micro-USB Connection From Jetson Nano to PC not recognized

[riises]

Hello All!

I have been trying to setup my Jetson Nano, but am running into a lot of trouble.

• I format the microsd using belenaEtcher
• J48 jumper is on the pins, so I can use DC jack.
• then plugging the microusb into my linux machine doesn’t do anything. Nothing pops up in the file tree, and no usb connection is found through terminal (ls /dev/ttyACM*)

It was working for a little while and I was able to get part way through the setup process, until i heard the device disconnected sound. I was using screen then ssh, but didn’t get that far. I reformat the sd, but still not luck on even getting a connection.

Does anyone have any suggestions on how to go about fixing this? Any help is greatly appreciated, thank you!

[linuxdev]

I’m not sure what you are doing, so let me ask first, which model of Jetson is this? Is it a Nano dev kit? If it is a dev kit, and not using a third party carrier board, then the SD card slot is on the module itself. If it uses a third party carrier board, then the SD card is on the carrier board, and not on the module. Also, third party carrier boards have eMMC memory, but the Nano dev kit does not have eMMC. Instructions are much different in some cases for third party carrier board models.

Assuming you use the barrel jack (I think it has to be around 5V on a Nano dev kit, but is around 19.6V on some other kits), does any LED light up? That would at least show proper power. If the LED does not light up, then there is no use going further since power issues mean nothing to log.

Note that dev kit models without eMMC have QSPI memory on the module itself, and that the equivalent of a BIOS and all of the boot content lives on QSPI for that model. Even if the SD card is perfect, if QSPI is incorrect it isn’t going to boot.

To set up QSPI the module itself must be flashed. This is separate from the SD card on those dev kit models. Instructions differ for third party carrier board models.

The /dev/ttyACM* is created from a USB serial UART of a particular chipset brand. Take a look at this Nano serial console URL:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/

Notice that the serial console uses header pins, and isn’t from the micro-USB connector. If you are looking for a serial UART to use, and not a serial console, then you should describe that.

[riises]

Thank you for your quick response!

I am using the Nano Dev kit, and the issue I am having is with the Micro USB. I was attempting to set it up using Screen and SSH because I was having trouble getting an HDMI connection to work, so I gave up on it. So to do that I was connecting the nano to my linux machine via the micro usb port.

This was working for awhile, then I am not sure what happened but it disconnected and it won’t connect anymore. I have tried multiple different cords, and multiple different laptops all with different operating systems.

edit: During the time that it did work, it was connected to ttyACM0

In regards to the power supply, it is a 5V/5A output and yes the green LED does turn on. I can also take off the jumped and plug in the microUSB as power and the green LED comes on that way as well.

Thank you again for your help!

[linuxdev]

Do you have a separate serial USB UART? In the URL I gave above, if you connect TX, RX, and ground to the pins for your particular model, then this should give serial console access. I’m not sure what all is available on the micro-USB, but I don’t think it is really intended for serial console. The header pins though (they are 3.3V level) should work. The serial USB UART cable itself is what would then produce the “/dev/ttyACM*” (or a different name if the chipset is a different brand).

[riises]

Alright I do have some kind of connection now! I have the minicom serial console, however when I plug power into the Jetson it stops at…
[ 14.466751] Please complete system configuration setup on the serial port provided by Jet.

and doesn’t continue as the one in the video does. Any ideas on this? Let me know if you want me to create a new ticket or not, I wasn’t sure if I should.

[linuxdev]

Normally you need to post the entire serial console boot log. However, this means the Jetson was flashed and is fully booted. The message you are getting is saying that you need to create your user account before it can continue. If you have a locally connected monitor and keyboard, then it should be available there. If this is only on serial console, then try rebooting the Jetson once without keyboard/monitor, and see if serial console then makes finishing first boot account setup available. If that still fails, then it is more problematic. For the latter you’ll probably flash again, but before flashing, use the “sudo ./tools/l4t_create_default_user.sh” command. This would modify the rootfs to already have first boot setup before you ever flash (you can’t distribute commercial products like that, at least not in California, for legal reasons, but there is no reason to not do this on your own system).

[riises]

Here is the full console https://pastebin.com/VGpZWJ3q

I don’t have it plugged in to a monitor, because for some reason when connecting to a monitor with hdmi, nothing happens. Because of this i was trying to do it headless, but to do that i needed screen and ssh to work, thus the microusb to work.

[linuxdev]

From what I could see it booted correctly. The problem is that you need to complete first boot account setup, but it isn’t dropping in to that.

Would you be able to run the above mentioned l4t_create_default_user.sh command on the host PC, and flash it again? If this is an SD card model, and does not have eMMC, then I suspect you can run that command directly on the SD card itself if it is mounted in the correct location of the host PC (this does require you to have an Ubuntu host PC; if you work with command line, then a wide range of Linux PCs will work; JetPack/SDK Manager is easier, and more automated though).

[riises]

Apologies, I don’t think I am understanding how to use the sudo ./tools/l4t_create_default_user.sh

I assume this is something that should be on the sd card? If so, I have no tools directory that I can find.

(It is the model with the sd card, and I do have a host linux pc.)

edit: I have found many tools directories, but I did `find -type f -name “l4t_create_default_user_.sh” and came up with nothing from root directory.

[linuxdev]

Normally, when one flashes, the flash software on the host PC has directory “Linux_for_Tegra/”. This is almost entirely the “driver package”, which is what actually performs a flash. There is a subdirectory, “Linux_for_Tegra/rootfs/”. This contains Ubuntu plus NVIDIA drivers. When a flash uses the default image, that image comes from the “rootfs/”. This is almost entirely what makes up the operating system (there are some edits of boot parameters and the actual kernel and device tree, but pretty much everything in “rootfs/” is what you see in a running system).

First boot setup has not been completed (normally) in “rootfs/”. If, from “Linux_for_Tegra/”, one were to run this:
sudo ./tools/l4t_create_default_user.sh
…then “rootfs/” becomes modified to include first boot setup. Any flash from that point forward adds that first boot setup so it is no longer required. You’re installing a user before flash.

The SD card models though tend to have people using some pre-canned SD card. So that content does not matter. However, the “sudo ./tools/l4t_create_default_user.sh” has no way to distinguish between a “rootfs/” with a bunch of files, and that of an SD card rootfs which is mounted there on the host. If you were to mount the SD card partition to overlay the “rootfs/”, and then run that command, it means the first boot setup is completed from the host PC on the SD card without the SD card having to complete this on the actual Nano.

The trick here is that in almost every case you need to make sure you are using the same L4T release in the flash software as you have in the SD card. If you were on a booted Nano, then you could find that release with:
head -n 1 /etc/nv_tegra_release

If your SD card rootfs partition were mounted over the “rootfs/”, then only that content would show up (the original “rootfs/” would again become available once the SD card is not mounted there). If you had your SD card mounted there, and you are in “Linux_for_Tegra/” of the host PC, then this would tell you the SD card’s L4T release version:
head -n 1 rootfs/etc/nv_tegra_release
(and actually you could just cd to wherever the SD card is mounted, then cd to the etc/ directory, and run “head -n 1 nv_tegra_release”)

The point is to install the command line flash software (or you could install via JetPack/SDK Manager, it all adds the same content, but command line is more flexible with host PC requirements). Then find the SD card’s rootfs, and make sure it mounts over the flash software’s rootfs. Then run the command for first boot account setup, followed by unmounting (we don’t want to corrupt our new work with a bad removal of a mounted filesystem).

Do you have an SD card reader on your Linux host PC? Incidentally, this is actually one place a VM won’t be a problem (so long as it sees the SD card). Do you have flash software already installed on the Linux PC?

[riises]

Thank you very much for the detail you put into your explanations, I am fairly new to this and I am learning a lot just reading what you are saying.

“head -n 1 nv_tegra_release” returned…
R32 (release), REVISION: 7.1, GCID: 29818004, BOARD: t210ref, EABI: aarch64, DATE: Sat Feb 19 17:05:08 UTC 2022

I do have an SD card reader on the host PC.

And I think I have realized one of the errors that I made. You talking about flash software makes me realize, that I just downloaded what I thought to be the correct SD card image, and put it onto the sd card then plugged it in. So clearly I am doing something wrong there, which makes me wonder how I got to the startup page for a little bit when it was plugged in to microUSB and using screen.

[riises]

Oh wait, I’m dumb. I forgot I used balenaEtcher to flash it on to the sd card. I don’t know if that changes anything.

[linuxdev]

The problem is usually that the QSPI memory must be flashed first. The boot content, and the equivalent of a BIOS, is on QSPI memory, which is in turn physically on the module, not the carrier board. This content must be compatible with the SD card image. It is quite common for an older QSPI content to be on the module (we’re not talking eMMC model, though there is some QSPI with some) to not be compatible with a newer release.

To update the QSPI you must flash the recovery mode Jetson while USB is connected to the Linux host PC. For a Nano (not Orin), you need either an Ubuntu 18.04 (preferred) host PC, or Ubuntu 16.04. You can use a wider variety of host PC on command line, but it makes for some more manual operation. Note that a VM can work, but tends to be a problem with improper USB setup (and WSL2 is worse since it needs a new kernel supporting loopback if one is to generate an image; working with existing images means only the USB part is likely problematic).

Do you have an Ubuntu Linux host PC? If not, I highly recommend dual boot over a VM. It might seem like a pain, but you could even add another hard drive to the PC and dual boot Linux to that and not even touch Windows (the bootloader installed from Linux would pick Windows or Linux at boot).