I have four new Jetson nanos. All of them went through the initial setup without problems, and I was in the Ubuntu. Then I rebooted them, and all of them failed to reboot. One of them green light shuts off after two seconds, two of them with green lights on but nothing happens on the monitor, the last one shows a system starting menu including options such as safe mode and restart, but I can’t select anything with mouse or keyboard. I really hope that it was because something I did wrongly. However, I have followed the Jetson Nano setup guid and setup 15 nanos and many of them worked, so I really don’t know what I could do wrongly. I really hope someone can help me to figure out what happened. I don’t wanna mail back and get replacements, that takes lots of time and doesn’t guarantee the new devices will work. I really need a solution. Please help.
The one with no green light tends to sound like the power supply is inadequate (Jetsons require exceptionally good power regulation). You should describe the power supplies. Also, are these dev kits? There are differences between dev kits and third party carrier boards with modules.
The rest could be the same issue, but what you’d need on those are serial console boot logs. See:
The power supply is DC 5V 4A, using power jack. I tried different ones. These are the dev kits B01 version.
For the debugging, do I have to use serial cable? Does USB cable work? I don’t think serial to usb cable is so common that every one has it.
The frustrating thing is all the four didn’t work. I really can’t believe all the four have hardware problem. However, I have done the same thing before for around 10 units, and therefore, I really can’t think of what could be wrong.
Most PC’s use a USB serial UART cable. One end is USB for the host PC, the other end has some sort of connector pins for using the 0.1" spacing header pins, but only if you are using the serial console of devices which are connected to that header. In the case of the versions of Jetsons which provide serial output to the micro-B USB, then you only need an ordinary USB cable with micro-B at one end. You might find this video useful since it is using individual wires and thus requires a USB-to-serial 3.3V logic level USB cable:
The JetsonHacks site is here, but I’m having some problems with it loading correctly:
Such cables do tend to need to be ordered online, just look for one that says “3.3V” for the cable voltage. If it mentions an “FTDI” brand chipset, that is even better (FTDI is always trouble-free so far as drivers are concerned).
Serial consoles provide details of boot even before Linux ever loads. In the case of something not booting up far enough to see an actual Linux console, then debugging pretty much mandates such a cable. If you are going to work on embedded systems you will find such a cable is quite useful in many circumstances, and probably worth your time.
You could of course describe in detail if all Jetsons are dev kits, and if not, any carrier board (custom carrier boards always require the manufacturer’s firmware unless their carrier is an exact match to the dev kit). You could also describe if the monitor is a true HDMI monitor, or if it uses cable adapters, and suggestions might be possible if you also provide exact details of your flashing (both the PC environment and steps). This is a lot of guessing, but you might not need a serial console cable if something is spotted.
Also, beware that power supplies for Jetsons must be unusually well-regulated. Charger units and many cheaper units just don’t have the stability (in millisecond range) to keep the Jetson booted. Even if technically the power supply has sufficient ratings I will strong suggest testing other power supplies if available. A serial console boot log might have clues related to this.
All the devices are dev-kits. The monitor is also HDMI monitor. You said ‘In the case of the versions of Jetsons which provide serial output to the micro-B USB, then you only need an ordinary USB cable with micro-B at one end.’ I believe my dev-kit B01 version has a micro-B USB port, so I only need to use USB cable then?
Check point 0 here if you are the one that never used sdkmanager before.
And if you want us to provide further debug, please get the usb-ttl cable to dump the log from uart. As what @linuxdev said in previous comment.
You can also directly flash the board with sdkmanager first. Because it is highly possible we still ask you to flash with sdkmanager after we check your log.
I will try the sdkmanager and update here. Thanks.
The Nano requires a USB UART cable to connect to header pins for serial console. See:
I mention some using micro-B USB, but that is actually the AGX Xavier.
Ok, thanks. I will look into buying one. It’s interesting to try debugging the issue, but it’s just surprising if jetson nano requires debugging so often. I don’t understand this part.
Just make sure when you find your serial USB UART that it is a 3.3V logic level. Some are DB-9 connectors which are way out of specs, others are 1.8V, and some are 5V. The magic voltage for the Jetsons will be 3.3V.
FYI, if you have a choice among several such cables, then I recommend one that says it uses the FTDI chipset.
I followed your instruction and directly flashed from sdkmanager/another host machine. All the four devices are working. Thanks a lot. Could you please explain a bit what its difference is from the flash sd card method is? What happened?
SDcard image does not include the bootloader binaries partitions. These components are on the QSPI-NOR flash over the module.
Thus, keep changing sdcard image or re-flash sdcard image won’t really change the software on QSPI-NOR.
But sdkmanager can reflash those.
Also, we suggest user to use sdkmanager and flash.sh tool instead of sdcard image. Actually, sdcard is just for beginner to have a easy entry. If there are some bugs happened, it won’t really resolve the issue.
Some added trivia: Earlier releases had less of the boot content on QSPI. Newer releases have almost all boot content on QSPI. Many SD card images from older days will work across a range of older releases. Newer SD card images work with several of the newer releases. Neither works particularly well when mixing the wrong QSPI content with the SD card content from different releases. There are times when you need to switch from older release to newer release, and the SD card itself is not enough to do the job. If you always also flash the Jetson, then you’ll know it is the right mix between QSPI and SD.
I see. Thanks for the information. This really helped.
Thanks for your information too.