Jetson Nano B01 doesn't boot after flashing DTB

JP 4.4
I’m following the procedure to make a driver for an image sensor. The procedure was provided by the manufacturer, was tried before on this exact board and worked perfectly.

JetsonNanoB01_CA378_procedure.txt (3.9 KB)

I seem to be able to follow without any problems until
“sudo make modules_install”
I tried again without success and for some reason carried on
and after the last step, which involves flashing DTB it just didn’t boot back up.
Didn’t think much of it, just reflashed SD card for the 10th time in the last 3 days but it still wouldn’t boot.
Green led is on.
No HDMI output.
No USB activity.
Can be put in force recovery.
Tried with a known working sd card with an image on it that did boot previously.
Heatsink is barely warm after 15 minutes.

Can it be fixed?

You should learn to use serial console to access the board.

It can tell whether the board is really booting up or not.

I connected an Arduino with the chip removed. Using Putty on Windows as a serial terminal. Baud rate is set to 115200.

I get a single LED flash the moment the power LED comes on after connecting power to the board but nothing in the terminal. I looked at it with an oscilloscope and it seems that Jetson just pulls down the TX pin.

No response to input on serial port

I don’t use windows to dump the serial console before so cannot comment.

Why not you just use ubuntu to check log since you already have a ubuntu machine to flash dtb?

Use the pure jetapck software setup to validate your UART first.

I tried with Ubuntu, SD card/No SD card, Force Recovery/no FR, serial opened with Screen, speed 115200, again, a single LED flash when connecting power (Jetson pulls its TX low) and nothing.
Tried connecting arduino’s tx and rx to see if my input in console echoes back, it does.

What did you expect force recovery mode will bring to you? I feel you misunderstand something here.

I didn’t expect anything FR to do. But I also didn’t expect to brick a board by following the same instruction that I followed successfully before. I have no idea why exactly it doesn’t work (Jetson Nano) but it doesn’t and I want it to work.

You said that the serial console may tell me if the board is booting or not. As of right now, the serial console didn’t output anything, not a single character, not a single bit, only drives TX pin low and that’s it. So it didn’t help.

All I know is that the board just didn’t reboot when it says it should. I might have flashed corrupted DTBs, but aren’t they uploaded to the SD card? Shouldn’t reflashing the SD card from the ISO fix this? JP4.5 mangling QSPI isn’t fixable, but what happened here?

My suggestion here is please try to use default jetpack from sdkmanager tool to flash the board. If even this process gets failure, then we consider this module has hardware defect. But if it can still flash, then we may need to find out why it cannot dump log.

Flashing dtb shall not cause the log fails to dump.

The whole procedure to debug this issue is like below.

  1. Flash your board with pure jetpack release → if even this fails, then possible hardware problem.

  2. If (1) is passed, try with HDMI and see if it can output something which proves that your board can still boot up → Now dump the uart log again, if even log not able to get printed in such situation, it means your uart console setup has something wrong.

I will try this once I free up enough space for SDK Manager to create temporary files

I don’t quite understand why do you need to do this.

This is just same as how you flashed the dtb. But this time you flash the whole board instead of only DTB partition.

cd nvidia/nvidia_sdk/JetPack_4.4_Linux_JETSON_NANO_DEVKIT/Linux_for_Tegra

This is already where the flash tool located.

SDK Manager seems to bloat itself a bit on every reflash (may not be true). It asks for 30gb of free space but the last couple of times I had to delete stuff (2-3 GB) to get these 30gb. I bought a new 120GB SSD for this Ubuntu install and it was clean just 4 days ago. So I don’t know myself why I need to do this.

You don’t need to install whole things. Just minimal software package for flash the board is sufficient.

Just take a easy example from desktop gpu… you don’t need to install CUDA to make your desktop run. Same rules to the jetson.

Refer to my post here to know what is minimal requirement.

My point in previous comment was "if you are sure “JetPack_4.4_Linux_JETSON_NANO_DEVKIT” on your host is pure jetpack content, then you can use that to flash, no need to use sdkm.

But if you don’t know if this is pure jetpack content, then let sdkm download it again.

In sdkm it’s stuck at Flashing - 99% and showed a message “It takes longer than expected” or something like that.

Click the export logs button on your gui and share log.

Here it is (469.6 KB)
Screenshot of the timeout message.

The flash log just stops here.

6.9873 ] tegrarcm --boot recovery
[ 6.9882 ] Applet version 00.01.0000
[ 7.0095 ]
[ 7.0096 ] Retrieving storage infomation
[ 7.0106 ] tegrarcm --oem platformdetails storage storage_info.bin
[ 7.0113 ] Applet is not running on device. Continue with Bootloader
[ 7.6285 ]
[ 8.3755 ] tegradevflash --oem platformdetails storage storage_info.bin
[ 8.3766 ] Cboot version 00.01.0000
[ 8.8176 ] Saved platform info in storage_info.bin

Did you ever use this host to flash your jetson nano before? I mean the whole flash. Not only kernel dtb.

Yes, I did, JP4.4 flashed onto a 32GB card not long before the board stopped booting. But to be fair I did delete JetPack_4.4_Linux_JETSON_NANO_DEVKIT folder before flash because it was containing potentially corrupted DTBs

Please directly put the board into recovery mode and then run below command under Linux_for_Tegra on your host.

sudo ./ jetson-nano-qspi-sd mmcblk0p1

And do you have other jetson nano boards on your side?

Good news: eventually it did work.
Face palm moment: “Have you tried inserting an SD card?” sdkm or don’t error out if there’s no SD card. And I cannot confirm for how long the card was absent but that happened between the reflash and now.
Behavior observed after successful flash: does boot. Does boot with another SD card(didn’t happen before).
Lessons learned: make checklists.