Identifying boot failure in TK1 Devkit

A year ago, I discovered my Jetson TK1 would no longer boot after having sat in a temperature-controlled room in a sealed container without any modifications since it’s last successful boot. A few days ago, I decided to get out the multimeter and to my surprise discovered there was power getting to the button which powers on the unit. Attempting to bypass the switch with the indicated jumpers failed to work, but power was also being detected running across these as well.

I have some old data I would like to retrieve from the unit and would like to get it back to bootable condition. Are there components I should specifically trace to detect failures? While, yes, I could just start with the schematics provided, I thought I would consult the forums first to see if I could get an idea of where to start.

I don’t know about specific components, but if you can get to recovery mode, then you can at least clone the rootfs partition. Do you still have the original micro-B USB cable? If so, connect that to your PC and try to put the unit in recovery mode (hold the recovery button down as power is turned on or cycled). Then on the PC you should see output from:

lsusb -d 0955:7140

If that works, then clone information is here:

Someone else may have recommendations of where to check voltage levels to find out if there is a replaceable component on the board which might fix this.

I do have the original Micro-B cable. It’s actually the most reliable Micro-B I own. And, sadly, recovery mode is not possible.

If other ports on the host, or even a second host (some computers have had issues in the past, e.g., old laptops, and switching to another computer revealed lsusb working) cannot see this, then I’m afraid there is likely hardware failure. Aside from power delivery issues, I’m not sure there is much that can be done in that case.

I was fairly sure it was a hardware failure. I really just wanted to diagnose the hardware failure to understand and possibly replace the component. It’s just very hard for me to fathom what component could have failed while it was safely stored.

The following shows numbering of pins on a micro-B USB:

Pins 1 is +5V Vcc, Pin 5 is ground. If you can verify this lacks 5V, then possibly:

  • The fuse is open.
  • The power rail is down.
  • The connector is breaking loose.

Micro-B is a terribly fragile design, and I’d think most likely the issue is the actual connector. Even if you get 5V the data pins might be failing, e.g., broken solder joint.

Interesting. It does lack 5V! I will look into why this is!

EDIT: Connecting the ground of the MicroB to the power connector of the TK1 unit, however, does show voltage. So I do not think the connection problem is the MicroB.

My replacement TK1 unit has arrived but JetPack 3.1 is missing from the downloads section.

Navigating to the most current JetPack page reveals a “To access older versions of JetPack, please visit the JetPack Archive.” blurb at the bottom of the page.

Clicking on the JetPack archive link allows you to select JetPack 3.1. However, the download link is as follows: meaning it is just executing a search on the embedded download page for “JetPack 3.1” and not actually accessing any archives.

Is this an oversight or has JetPack 3.1 been permanently discontinued without warning?

EDIT: In a 2017 post on the TX2 fourms, the 3.1 JetPack can be downloaded from here. I highly suggest NVIDIA fix this issue as archived builds may need to be accessed in the future and the current archives link takes you in a recursive loop of digging into “archive” areas which provide no downloads. Thank you.

Looks like you are right, bad download link cycle.

The listing of older releases of JetPack is here:

The 3.1 version specifically goes here:

And then the “download” goes to the empty Jetson Download Center.

As a workaround, it would be possible to flash on command line using the driver package plus sample rootfs. Unfortunately, this is only flash and does not include CUDA. R21.7 is the most recent L4T release for the TK1, and if interested, see (you may need to log in and then go to the URL a second time):

Basically, if you use command line, you download the driver package, unpack it as a regular user, download the sample rootfs, unpack it into the “Linux_for_Tegra/rootfs/” location using “sudo”, then run “sudo ./” from the “Linux_for_Tegra/” location. After this you can flash as many times as you want and do not need to repeat the previous steps. Flash would be something like this with the TK1 in recovery mode:

sudo ./ -S 14580MiB jetson-tk1 mmcblk0p1

Meanwhile, someone may be able to check on missing downloads.

I am not sure why the administrator marked your above comment as the answer, because not only did I not follow these instructions, as in my edit I provided the correct link to JetPack 3.1, but the post also does not help correctly identify the boot failure in my previous TK1 unit, which is the title of the thread.

Administrator, what is the meaning of this?

If you still have the old unit, and recovery mode does not work, then there isn’t much which can be done to recover through cloning, and flashing won’t be possible. Identification of the boot failure then becomes one of troubleshooting the hardware itself. There are schematics available, but are you interested in component level debugging?

I understand that. I have been going over the schematics (that also no longer appear to be available for download), but the process is slow because I’m not very adept nor have great resources. But for the administrator to mark your non-answer to the topical question as the answer for the thread is very absurd. Then again, they have been doing nonsense like that since I first purchased my TK1 unit originally.

Also, I would not want to flash my old TK1 unit, and as stated previously, I need to recover data from it. I do not know if efuses or specific keys would prevent me from swapping the onboard flash memory to the working unit and would allow me to boot it.