I have been using my Jetson Nano for a few days without any problems. It was running motion and recording events just fine. I wanted to change the settings again yesterday, and restarted the Nano. It restarted, I could connect to it for a few minute, then the connection crashed - I was connecting using VNC through ethernet.
The Nano doesn’t seem to start at all, since. I have plugged it to a screen but nothing shows up (out of the screen’s no signal). Power LED is remaining on. Both ethernet LEDs remain on as well (green and orange).
I am sure the SD card isn’t responsible. I actually had 2 SD card formatted and working, and the Nano doesn’t start better if swapping them.
I had a look on the forum, but could only find info where the Nano would not start, but shows the nVidia logo on screen (doesn’t show in my case). One of the advise was to use the chat and see with RMA to repair the board. I have tried the chat, but was told that they could not help (not trained on Jetson Nano) and that I would have better chance posting here.
Please help! I read about J40, power, reset and force_recovery pins… would any of those possibly help? And what to do with them if yes?
No, I can’t ping the address. There is obviously no communication on the ethernet port (LEDs remain on, no flicker on the orange - network is meant to be 10MB/s, so usually, green ethernet LED was usually off).
Using Ubuntu, I could not see any connection on the network, using nmap. ip would show ethernet low. Plugging in another device (raspberry pi), ethernet would go up and shows on network.
Main concern, I realised that ethernet LEDs are on even if cable is not connected. They turn on as soon as board is powered.
I’ll look into serial console now. I doubt it will show anything at all, but I am curious to see. It might take a little longer… I need to find and set and arduino board to connect on the pins. I’ll update once done.
I just want to double check that the UART you used is from the J44 header…if this is confirmed, then there is definitely an issue. Not necessarily anything serious, e.g., it could just be a power supply not well regulated. I see the unit was previously working, and probably with that same power, but has anything been changed so far as connected peripherals which might even slightly change power consumption? If nothing else has changed, then likely you do have a failed unit.
Do you mean J41? The instructions you provided to connect to the serial console are using J41 Header; pin 6 for GND, pin 8 for TX (to RX) and pin 10 for RX (to TX).
But that is true, it is also talking about a second UART on J44, specifying that it is helping with start-up issues. I will try to find the J44 pin callout and try again (they actually have another article for it: Jetson Nano Style - Serial Console - JetsonHacks). I’ll post when done.
But no, no changes with peripheral happened in between the “working and not working”. Or only to lower possible consumption - I disconnected the webcam I was using previously in case that would help the board starting again.
I am not sure what you mean about that. I was actually searching for some info about “recovery mode” before posting here, wondering what the J40 header (with power, reset and force_recovery pins) could help… please, let me know what to do with those/link a tute that I could refer to if they may!
But as it is, the board seem to get stuck brain dead as soon as powered.
Edit: I found your post there:
I tried it (but didn’t put the jumper over J48 because powering my board from USB) and got nothing. Powered up, jumper over force_recovery, jumper over reset, removed rst jumper, then recovery’s… blank screen, no serial console output, nothing. Just those damn power and Ethernet LED remaining on (despite no ethernet is connected)…
Just not the best time to look into RMA, hey! But so, what is the process? I get in touch through the chat?
@linuxdev,
No matter if I login, then return, I keep getting a “# File Not Found or Link has Expired”.
I could not be sure if the documentation and my board was the same revision, but I have checked the silk print on the board itself.
Both J41 and J44’s GND, TX and RX pins seem to be correct (J44: 6, 2, 3 and J41: 6, 8, 10)…
I guess you always use the sdcard image but didn’t try sdkmanager before, right?
The recovery mode is to use when we are going to re-flash the device. It is like formatting all the storage and re-install the OS again. When device is in recovery mode, you need to use the micro usb cable connected to a ubuntu host and then use sdkmanager to flash your board. When device is in recovery mode, there would be no response from monitor. (OS is shutdown at this moment).
Also, I notice many users suffer when their first time to sdkmanager, so I wrote this wiki page to help clarify some questions.
@WayneWWW Indeed. I only used the SD card si far… I think I downloaded the sdkmanager but didn’t try using it. Guessing this is the perfect moment to… I’ll follow your wiki and indicated tute and update accordingly.
Update: I remember why I didn’t proceed further experiementing with sdkmanager, it requires Ubuntu 18.04 and current install is 19.04. No big deal, I installed 18.04 on a virtual machine.
Yet, I won’t be able to try the recovery process/flashing for a couple weeks… I am running low on data download for this month and total is close to 6GB (4GB if discarding SDK components)… I can’t afford that at the moment, but will update as soon as managing to download the packages.
@linuxdev Thanks, I found the carrier board documentation. Not sure what revision it is, though. I’ll look into that if/when needed.
@WayneWWW I’d agree. Also the way it happened… working, then suddenly crashed and not able to start since - not even to start at all, to say the least.
As for trying another SD card… I had 2 cards flashed, so to make sure that I could always confirm one is working if not the other. Sadly, swapping one with another gives the same result, making me think the SD card is not responsible.
Yet, I will flash a third with the original image, just to confirm again.
Update: nop, same result with another SD card. Board is powering up, LEDs are and stays on, but no feed on screen or console…
@WayneWWW Hi, I finally could download and test the sdkmanager… guessing I could have looked into the process earlier, to find out that flashing the device would require a network connection, which I can not get.
The Jetson Nano DevKit never shows up on the network, despite that it was perfectly showing up before.
I have tried using USB (@192.168.55.1) or Ethernet (@given IP address). Nothing, I can’t ping the address…
I wanted to confirm functionality; using Ethernet, I could ping a Raspberry Pi as expected.
Please, confirm - I should be able to ping the Jetson Nano before flashing it? I mean… I have been following your tutorial and would believe so already.
But so… filling in a RMA request? How should I do that? And… how can I actually process the return when post services are locked down to essential services?
Flash the device does not need the network connection
I think there are some misunderstand here.
There are two parts in so-called installation of sdkm.
Flash the board. The OS on tegra is dead at this moment. So it is not possible to ping or use any network in this phase. Nano is just like a brick. Only need to put on the usb cable, put the device into recovery mode and run the flash.sh script. And then you shall see the flash log (successful or not).
Installation of all other sdks. It is actually just sending some deb files to nano through network and use it to install something like CUDA/OpenCV…etc. At this moment, the OS is working. Of course the OS is working based on the flash process is successful in step (1).
@WayneWWW OK, I’ll try again… I guess it is what you try to explain in your tutorial, by directly using flash.sh?
I tried the “sudo ./flash jetson-tx2i mmclkb0p1” but it came up with a “flash” command doesn’t exist, so just gave up… I’ll try again, reading more carefully the help page, using "sudo ./flash.sh . More specifically trying to find how to get the proper device and board ids…
Also one thing to mention here because I think you may be not that familiar with ubuntu host.
When you use “./” to run some executable on linux, it is searching the executable file name under your current working path. Thus, when you used “./flash”, it was trying to search an executable file named flash and it finds nothing because the correct script name is flash.sh.
