Jetson nano cannot exit forced recovery mode

After burning the uboot for my Jetson nano car, I have removed the short circuiting of the 9,10 serial ports of the j50. I don’t know why I still cannot exit the forced recovery mode. Now, the OLED screen behind the car is not lit, and I cannot access the uboot and ubuntu systems through serial communication

Recovery mode is a pure hardware behavior. Cannot exit it means hardware side issue.

But the new motherboard and core board that I just replaced a week ago cannot be due to hardware issues. Is there any other system configuration that prevents me from exiting recovery mode? I only know how to cancel the short circuit of pins 9 and 10 of J50 to turn off the recovery mode. I don’t know if I accidentally touched another pin, which prevented me from turning off the recovery mode

請問你這裡的底板是指NVIDIA devkit還是其他客製化底板? 還是說你也不知道?


Is the motherboard here indicating NVIDIA devkit or other custom board? or you don’t know the difference either?

The one I replaced the previous week was the motherboard and core board of the Jetson nano

Hi,

感覺你的回答好像還是搞不太清楚狀況.
這個forum分類上面所有人的板子都是jetson nano. 你的回答沒有提供什麼有用的訊息.


It sounds like you are still not in the situation.

Everyone’s board in this forum is jetson nano. Your reply just told me you are using jetson nano. It is a dummy reply provides no information.

Sorry, I just thought you asked me if the motherboard was NVIDIA or something else. My board is using NVIDIA devkit

OK, if this is nv devkit, then removing the jumper is sufficient.

Do you have other carrier board or module to validate if this is a situation only happened to one carrier board or one module but not every module/carrier board?

I only have this board left, and I cannot verify if each board cannot turn off the recovery mode. However, I also short circuited the sys and gnd pins yesterday and found that the power light was off. Then, I realized that I had short circuited the wrong one. Then, I short circuited the fc and gnd again to enter the recovery mode and burned a new uboot. I can guarantee that the new uboot is fine, But after the successful burning, I removed the jumper and inputted lsUSB into the virtual machine. I found that the board was still in recovery mode, and I couldn’t see any information on the putty terminal when connecting to the car using a USB to serial cable putty

Hi,

Could you just flash your board with pure sdkmanager and dump the log from serial console since the beginning of flash?

Can sdkmanager use the default uboot? I haven’t used sdkmanager yet. I’ll try again tomorrow. It’s a bit late now and I need to go to bed first. Thank you for your help today

What does that mean default uboot…??

Sdkmanager provides the pure jetpack… everything from it is the pure and default one to jetson…

Are you sure it really is in recovery mode? What is the reason? I suspect it is just a failed boot and not really recovery mode.

First, a VM very often fails. For a VM to actually work the USB has to be set up correctly. Even when USB is first detected, a flash results in disconnect and reconnect, and at this point most VMs (unless set up for this) fail to reacquire USB. Life is much less problematic when using native Ubuntu (18.04 for a Nano).

Recovery mode itself is just a mode, and does not actually change anything. All recovery mode does is to turn the Jetson into a custom USB device, which in turn means it needs a custom USB driver. That’s the “driver package” in the flash software (and JetPack/SDK Manager is a GUI front end to the driver package).

If a Nano is fully booted, and a micro-B USB cable is plugged into the micro-USB (micro-OTG) connector, then the Jetson of a fully booted system also goes into device mode since it runs some network device and mass storage emulation software. That looks the same as recovery mode in the sense that it is also device mode, but this is not susceptible to flash.

In the case of trying to flash and having something look wrong, especially if using a VM which might succeed with part, and fail when USB is gone, it is expected that the flash itself has caused the failure (and this would not be hardware). Actually being unable to leave recovery mode is a hardware failure, but I’m going to suggest it is about 99.999% likely it isn’t really stuck in recovery mode, and is instead just failing very early boot.

Note that Jetsons do not have a BIOS. eMMC models put this “equivalent” content in partitions, while SD card models put this content in QSPI memory. Flashing anything other than the root filesystem (o/s) implies you are likely simultaneously flashing that BIOS equivalent software. Anything at all which is wrong with this means you won’t be able to boot, and I think this is what is wrong.

A serial console boot log is extremely useful, and it is almost impossible to do anything other than to flash the system again (without a VM) to get any further…unless you have a serial console log (but considering the previous flash failure, you’re likely to again be told the need to flash…but you could know the hardware is working or failed with the serial console log).

Incidentally, because Jetsons (and many embedded devices) do not have a BIOS, most boot stage software “out in the wild” is not compatible. That software has to set up power rails and clocks and device tree in a specific order and timing. NVIDIA does provide boot source code, so if you use U-Boot from some other supplier, it is likely never going to work. Also, in more recent releases of Linux for Tegra (“L4T”, which is Ubuntu with NVIDIA drivers), and actually in some not so recent releases of L4T, U-Boot was removed, and CBoot had several U-Boot features ported to it. So most likely you are using CBoot which looks and behaves much like U-Boot. That CBoot is available as source.

Is this an SD card model, or an eMMC model? That changes a lot. Can you get a serial console log? This would beat replacing hardware only to find out the flash software was wrong, or that the VM simply cut off flash.

Also, when updating some specific partition, e.g., something related to device tree or CBoot, you cannot just blindly flash it. You must make sure the size of the content fits within the existing partitions, otherwise it will be truncated (or it will overwrite part of another partition). If you set up flash with custom CBoot, and then flash everything (versus just flashing CBoot), then it is possible changing partition sizes might be adjusted (although it is equally likely you’ll need to change an XML file…but even if all other partitions are the same size, a change in a middle partition could need moving other partitions over to a new offset…flashing just one partition won’t do that).

If I use micro USB to connect the car and virtual machine, and then directly use the flash command, and if I don’t short circuit pins 9 and 10, I can succeed, does it mean that the board has been in recovery mode all the time

我前面請你抓log請問有抓了嗎…


Did you capture the serial log as my previous comment asking for?

I’ll emphasize what @WayneWWW asks for: A serial console log. That log works even before Linux ever loads, and it also has different logging during recovery mode flash. Something like PuTTY can easily be told to create a log file before power is ever applied to the Jetson, and then boot the Jetson, and the entire boot sequence can be viewed and there is no need to guess at that point at what is going on.

Technically, if flash actually succeeds without ever putting the Jetson in recovery mode, then you would have found a problem. I’ve never heard of it happening (that doesn’t mean it does not happen, but I would be very very surprised). Why not get the serial console boot log, since that would answer without any guessing? You could also add the serial console output during a flash, but please add the log for what should be normal boot.

I’ll also emphasize that VMs are usually problematic for flashing, especially WSL2.

1 Like

Today, I finished cleaning the entire machine and the recovery mode automatically turned off. At first, the root cause of not being able to putty connect to the car was that the recovery mode was not turned off. Now, the 9,10 pins of the J50 have returned to normal, and the mode can be restored by plugging and unplugging the jumper cap switch. However, I still don’t understand why the 9,10 pins malfunctioned after cleaning the uboot. Also, as you mentioned yesterday, you asked me to capture the log of the serial debugging console, I think it’s the one that connects pins 3, 4, and 7 of J50 and uses putty to view the login information, right? However, due to the inability to turn off the recovery mode, I cannot view any information in putty

Yesterday, I listened to the advice of the technical staff from the Micro Snow flagship store where I bought this board. She asked me to reset the machine to turn off the recovery mode and it was successful. Thank you for your help

Hi,

Sorry to say that. Would you mind clarifying some of your comments in Mandarin? I am really not quite sure about what you tried to say when it is in English.

For example,

She asked me to reset the machine to turn off the recovery mode and it was successful.

I don’t understand what you want to say here. What kind of reset? Hardware reset? Software reset? I feel there is no such thing as per my knowledge on jetson nano…

After you remove the jumper, just power on/off the board will definitely make you not it recovery mode…
If this is what you said, then it sounds just a small silly mistake that is caused by not familiar with jetson devkit…

As for this, my point is you need to start the flash process. RCM won’t print log. But if you start the flash process, it will show the log. I was trying to ask for that log.