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.
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.
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.
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.
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.
Flash your board with pure jetpack release → if even this fails, then possible hardware problem.
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.
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.
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
Good news: eventually it did work.
Face palm moment: “Have you tried inserting an SD card?” sdkm or flash.sh 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.
