hi,
I have a jetson Nano 4GB model B and when I flashed the SD card I was able to setup the Jetson but after the configuration suddenly the Nano turned off. When re-powering it the green light goes on but there is no hdmi output (the display remains dark no nvidea logo also). I have reflashed the SD but no results so far.
I used a 5v 2.1A adapter but also tried directly powering from laptop which could potentially hit 3A.
Thanks in advance!
Quinten
Hi @quintene,
This seems to be the behavior when it starts on recovery mode. Could you check that the Jetson Nano is not configured to start on that mode?
If you are using the devkit you should make sure that the pins FC_REC and GND in the header below the SD card socket are not connected.
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com
Hi Jimena,
Thanks for your reply!
Unfortunately the pins are not connected but I tried (after multiple sd reflashes which didn’t made any difference also tried another sd) to connect the pins and try the recovery mode but this also didn’t help. I removed the jumper again and still no progress.
Is there any other way that it could be stucked in recovery mode? Or any other thing I could try?
Thanks in advance!
Quinten
At this point the answer will always require a full serial console boot log. This will say a lot.
@linuxdev Thanks for your reply!
If I start in headless mode (with a jumper) and micro usb serial connection will I also be able to be debug the problem? I do not have the required power supply yet… Otherwise I will get my hands on a usb serial connector.
Thanks in advance!
Serial console works regardless of headless or not. It has no video driver or network driver to worry about. You cannot interact in recovery mode, and although a log of serial console during flash can be useful to debug a flash issue, this is not what you want (don’t use the jumper). Just boot normally with the serial console running and logging enabled prior to starting boot. You can experiment without logging until you see boot text, but at some point you will need to clear the serial console and then start logging, followed by turning on the Jetson. This should provide logs from boot stages long before ever getting to the load of Linux. So you do need the micro-B USB cable. Dev kits normally come with those (“charger” cable quality is usually terrible).
First of all thanks @linuxdev for the help.
After ordering the right cable I am now able to see some error logs… (which I put in an error log file)
It seems like some boot partition is corrupt but I have tried multiple reflashes with different SD cards. Could it be some on board memory? In the meantime I found some people trying to repair the jetson with the Nvidea SDK manager Install Jetson Software with SDK Manager :: NVIDIA SDK Manager Documentation.
Do you suggest this solution as well or do you have any other directions to explore?
I did see you post on a similar issue on the topic Jetson nano 4gb is not booting suddenly
I’am not entirely sure how the solution used flash.sh or where this file came from? Hope you could help me out.
Thanks again!
Quinten
error_log.txt (89.0 KB)
Your log shows a repeated QSPI corrupt memory error (see “NvTbootFailControlDoFailover”). This in turn is part of QSPI memory.
The background is that SD card models of Jetsons only put the rootfs on the SD card. Jetsons in general do not have a BIOS, and so the equivalent of what a BIOS does has to be performed in software. That software has its own partitions (even if you can’t see them). eMMC models tend to put that content in ordinary eMMC partitions, but SD card models put that content in QSPI memory instead (which is located on the module itself).
Whenever you do a “normal” flash of any Jetson it is flashing everything. This means it is similar to flashing the BIOS of a PC’s motherboard, the bootloader, and the actual operating system. That content (for your case) is basically early boot software (before the bootloader even runs). You can’t really “brick” a Jetson since it does not have a BIOS, but it does mean you need to run flash software from another PC (in this case running Ubuntu 18.04).
When a Jetson is in recovery mode it becomes a custom USB device (and the micro-OTG port is used for flashing). Custom USB devices need their own driver, and the flash software (underneath the other layers) is called the “driver package”. When you download and install JetPack/SDK Manager to your host PC, this is part of the content it installs. JetPack is a GUI frontend to flashing, and the SDKM is a network utility on top of that. The actual content flashed is “Linux for Tegra” (L4T). Flashing the module itself will flash the QSPI. You’d just use the same release as that which created the SD card.
JetPack and L4T releases are tied together. Knowing which release of either will tell you the release of the other. You can check here for releases:
So basically you’d download and install sdkmanager to your Ubuntu 18.04 host PC. Then you’d put your Nano in recovery mode, with the micro-B USB cable connecting it to the host PC. Finally, you could flash it. JetPack/SDKM might need to be told you don’t want to install extra software to the host PC (which can be used if you are developing), or that you don’t want to install extra packages to the Jetson (it might run out of storage space on some models). In general though, the docs for the particular release are on the same web page as that particular release.
When you install the flash software to the host PC, then it will create this directory:
~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra
You can run “sdkmanager” as a regular user for the GUI, but you can also perform just flash steps (such as flashing QSPI) on command line if the Jetson has been connected to the PC in recovery mode. Within that “Linux_for_Tegra/” subdirectory you will notice several “.conf” files (see “ls *.conf” when at the “Linux_for_Tegra/” location). A typical Nano command line flash goes something like this from that location after consulting for the “.conf” file matching your Jetson model (you might need to consult those docs for the 4GB model):
sudo ./flash.sh jetson-nano-qspi-sd mmcblk1p1
(thus there is a file “jetson-nano-qspi-sd.conf”)
Note that eMMC models flash everything. SD card models often have the user create the SD card separately from flashing the Nano since QSPI is on the module itself and that content does not go on the SD card.
Incidentally, the first line of file “/etc/nv_tegra_release” tells you the L4T release you have. You could mount your SD card on the host PC and examine that before downloading SDKM in order to get the same release. If you don’t mind changing release and losing the SD card, then you could ignore that and just get the most recent release compatible with the Nano.
Thanks! @linuxdev After flashing it worked again!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.