I have a Nano (called number 2) that was put in storage for a couple of months. Now I go to use it I find it’s acting strangely. Initially I got no video on the HDMI output. I tried re-building the microSD card, and got the Ubuntu install screen up, but the UI would just freeze for a few secons at a time, then continue. Eg. click on continue, nothing happens. … Then a few seconds later it responds. I tried using the SDK Manager on Ubuntu 18.04LTS to re-flash the Nano. On that machine I updated all the packages, ran SDK Manager and updated that too, as well as downloading vast volumes of goodness knows what when SDK Manager prompted me. Finally, install to Nano via the USB port. At the same time watching the console USB with Minicom on another machine. It reached a point where it tells me to log in on the Nano and complete the Ubuntu install. It’s looking good and I select time zone, but at the screen where I configure my login name it freezes just as I am about to type my password. No KB response, no mouse cursor response. I have another Nano (called number 1), and that’s behaving itself. Prior to running SDK Manager I tried swapping microSD cards between them and the fault seemed to be with Nano 2. Hence the plan to re-flash it with SDK Manager. That doens’t seem to have helped so maybe it’s faulty? Here is the output from the serial console. Anyone have any ideas?
Oh and for what it’s worth I’m confident in the power supply I’m using - it’s a 4A model. I have used that as well as a 2.5A official Raspberry Pi power supply on the Nanos and the fault doesn’t seem to be tied to the power supply I use.
I got almost the same problem when I use SdkManager to flash Jetson Xavier NX(with Nano’s carrier board B01),SdkManager version is 1.1.0.6343,Jetpack version is 4.4 DP.
@JerryChang, I remove the previous downloaded deb file and delete JetPack_4.4_DP_Linux_DP_JETSON_XAVIER_NX/Linux_for_Tegra folder,But Jetson OS image status always show “OS image ready”. What should I do to re-make the OS image?
When I used SDK Manager yesterday it went and downloaded 4.4DP and installed that onto the Nano. The resulting Nano (Nano 2) exhibited the problems I documented at the start of this topic.
Just now though something has happened to question my sanity. I took the microSD card I was using in Nano 1 (built using a Jetpack 4.2.2 rev.1 SDK Manager months ago IIRC), and put that in Nano 2 and now Nano 2 is working fault free. I am sure this combination exhibited problems yesterday! This brings up the question below:
Q) When using SDK Manager to install to a Nano, is it JUST the microSD card that gets altered in the Nano, or is there some other stateful mechanism on the Nano that gets altered as well, such as some built-in FLASH or EEPROM that I (currently) don’t know about?
Hi Jerry. I am not quite sure I understand your sentence.
I Have a Nano (#1) that I set up months ago, I think with Jetpack 4.2.2 (rev.1). It works fine.
I have a second Nano (#2) that I also set up months ago, but when I started using it again the other day after a break of a couple of months it did not boot. So I investigated further. It seems there were varying and inconsistent errors present on the serial console. So I tried using SDK Manager to install 4.4DP. Then I get the errors I document in my first post.
I have since taken the microSD card out of Nano #1 and put it in Nano #2. Now Nano #2 is running trouble free. I don’t understand why as I’m pretty sure I tried this combination the other day and it too had problems. I will let it run over night and see if it is OK tomorrow. If it is still OK tomorrow that really makes me wonder if the SDK Manager did something to Nano #2 to change it. Something like on-board EEPROM or some low-level flash. Something other than the microSD card. So my question again:
Q) When using SDK Manager to install to a Nano, is it JUST the microSD card that gets altered in the Nano, or is there some other stateful mechanism on the Nano that gets altered as well, such as some built-in FLASH or EEPROM that I (currently) don’t know about?
If I know the answer to that, then I may well be able to explain why Nano #2 is now working.
yap, a complete flash on Nano would also update on-board data.
since I don’t know which Nano version you’re used. you may refer to flash configuration files for more details.
for example,
$OUT/Linux_for_Tegra/bootloader/t210ref/cfg/flash_l4t_t210_spi_sd_p3448.xml
@martin2wu0d it’s a software issue, i have a new board and only the SD image for JP4.3 works, i did not use any JP SDK or anything on mine. same behavior, locks up, slow and impossible to use.
@JerryChang just download the SD image in the the tutorial and try it… its the same thing, i have a new nano and only the second last SD image works. it’s broke. i have a post about it and it’s been over a week now. people with new nanos will run into the same thing.
OK that’s good to know that there is more to the equation than Nano+microSD, and is more like Nano+Nano_EMMC_config+Nano_SPI_config+microSD according to what I see in that …/cfg/ directory.
Hi digibluh, after leaving the Nano running over night it had stopped responding this morning. No console terminal nor HDMI. So I thought instead I’d give JP4.3 a go. So now a few hours later (everything seems big and hence slow) it had downloaded but the installation to the Nano failed. VisionWorks on host seems to have failed according to SDK Manager. libvisionworks was not found, nor was libvisionworks-dev or libvisionworks-samples.
I have not had a great time trying to get this to work, plus I have spent days on it. You know what it’s like when the device seems unbearably slow, but yet it’s still working. It makes you want to keep on trying. But I think it’s time to throw it out the window and run with an alternative. Maybe I’ll stick it in a drawer and try again in six month if there is a new JetPack at that point.
I still have one working Nano (#1) so I guess I should be happy. Now I know what I know, I’ll be very careful not to mess with its config!