Jetson TK1 wont boot - help me help the kids - any help is REALLY appreciated.

I’m trying help with computer vision for a First Robotics Competition and was handed a Jetson TK1. But it looks like lights on, nobody home situation. I loaded Ubunto 14.0.4.1 LTS on a laptop as a host.
I plugged in a HDMI monitor, tried to ping tegra-ubunto, but noticed the Ethernet port on the TK1 has no lights on. The monitor shows no input.

I tried to run recovery and and load OS with this: JetPackTK1-1.2-cuda6.5-linux-x64.run, but it got an error message and said error while flashing.
The command lsusb doesn’t show the Nvidia device.

Any ideas what to do?
Can I boot from a SDCard?
Should the monitor work regardless of the state of the boot loader?
I have no experience with any of this, so ANY help is helpful.

Here is flash_os.log:
Running flash_os
copying bctfile(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg)… done.
copying bootloader(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/u-boot.bin)… done.
populating kernel to rootfs… done.
populating jetson-tk1_extlinux.conf.emmc to rootfs… done.
done.
Reusing existing system.img…
done.
copying dtbfile(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)… done.
copying cfgfile(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg… done.
creating gpt(ppt.img)…

*** GPT Parameters ***
Device Sector Size ------- 512
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
FS Buffer size ----------- 4096
Partition Config file ---- flash.cfg
Visible partition flag — GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none

*** PARTITION LAYOUT(20 partitions) ***
[ BCT] BH 0 16383 8.0MiB
[ PPT] UH 0 4095 2.0MiB ppt.img
[ PT] UH 4096 8191 2.0MiB
[ EBT] UH 8192 16383 4.0MiB u-boot.bin
[ LNX] UH 16384 49151 16.0MiB
[ SOS] UH 49152 61439 6.0MiB
[ NVC] UH 61440 65535 2.0MiB
[ MPB] UH 65536 77823 6.0MiB
[ MBP] UH 77824 90111 6.0MiB
[ GP1] UH 90112 94207 2.0MiB
[ APP] UV 94208 29454335 14336.0MiB system.img
[ DTB] UV 29454336 29462527 4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[ EFI] UV 29462528 29593599 64.0MiB
[ USP] UV 29593600 29601791 4.0MiB
[ TP1] UV 29601792 29609983 4.0MiB
[ TP2] UV 29609984 29618175 4.0MiB
[ TP3] UV 29618176 29626367 4.0MiB
[ WB0] UV 29626368 29630463 2.0MiB
[ UDA] UV 29630464 30773247 558.0MiB
[ GPT] UH 30773248 30777343 2.0MiB gpt.img
copying flasher(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)… done.
Existing flashapp(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/nvflash) reused.
*** Flashing target device started. ***
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
USB device not found
Failed flashing ardbeg.

So far as a desktop versus Jetson goes, the monitor has minimal drivers in the desktop BIOS, but Jetson does not have a BIOS, and so monitor output only succeeds if Linux is actually loaded and at a point with some minimal framebuffer running. The 9-pin serial port is text only, and does not need any video driver, and so this is by far the easiest way to see what is going on early in the boot process (even at the boot loader stage the serial console can see boot software output). So, serial console is recommended in times like this. Serial console setting is 115200 for speed, 8N1.

lsusb should show the Jetson if the supplied type-B micro USB connector is connected to the host and then only if in recovery mode. Recovery mode button would be held down, and either the power applied or power reset tapped (there is no special time delay, if recovery button is held and power is applied or reset JTK1 should go to recovery mode). Once in recovery mode, this command should return something other than being empty:

lsusb -d '0955:7140'

Can you double check that recovery mode has been entered (or properly keyed) and that lsusb shows the device while using the micro-B cable?

Thank you so much for your help.
I pushed recovery mode, turned on power, press and held reset for 2 seconds, but lsusb -d ‘0955:7140’ did not return anything. I will try the serial port tomorrow.

Unless there is hardware failure, lack of response in lsusb for a recovery mode Jetson would typically only be seen if there are USB problems. Running from a VM instead of an actual Linux install has been known to do this (the USB setup for a VM is another of those details that gets missed). The serial port should be able to clarify things.

Hi I hooked up a serial port (looks like it needs a null modem), and turned it on and nothing. No output.

Null modem is correct. The speed 115200, 8 bits, no parity, 1 stop bit (115200,8N1). Depending on the cable, software flow control works, but many support CTS/DTS. It seems like you may need to start RMA, as even when serial console settings are incorrect, I’d expect to at least see garbage text. One exception might be if a USB serial UART did not have power applied before it started…you could simply reset the Jetson again without power off to be sure.

See here and search for RMA near the top:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/

Try this:

  1. Make sure the micro USB and power cables are connected
  2. Press and release power button to make sure the device is powered
  3. Press and hold recovery button
  4. Press and release reset button
  5. Wait 5 seconds
  6. Release recovery button
  7. Check lsusb on the laptop for the nvidia device (0955:7140 according to linuxdev above)

Hi, had the same problem out of the box. DOA except for the power LED.
Installed ubuntu on and external drive on my iMac and booted into it. I performed the forced recovery and reset steps as stated above on the TK1 with the mini sub cable connected. Then the lsusb command in the terminal. At that point flashing was successful and the TK1 show up on the lan network when connected to my router.
I flashed ver 1.2.
Version 2.0 will flash but refuses to accept the default login user and passwords for me.

Whenever a first ssh connection occurs, the ~/.ssh/known_hosts file is updated. Changes are then considered a possible man-in-the-middle attack if keys change. Each flash can change keys. Were the login name/pass used over ssh? If so, this might be the reason. Also, ssh via non-sudo ubuntu might cause a difference in this versus ssh via sudo ubuntu (the known_hosts may be in different directories).

Thanks for everyone’s help. Does the RS232C really use +/-15V voltage levels? (what I would consider normal rs232). I’m struggling to find where it specifies this in the documentation. Does anybody have a link?

RS232 actually has a range of voltages for the standard, but some serial ports use different levels than others. The cables used on a TX1 are specifically 3.3V. For the D-shell of the TK1, I use this:
http://www.newegg.com/Product/Product.aspx?Item=N82E16812156039

I think the versions which have the actual D-shell tolerate the full range of voltages expected from the standard, while some specialty cables expect operation at voltages such as 3.3V and may or may not tolerate wider voltage ranges (for the TX1 I’d suggest matching 3.3V).

The RS232 standard itself is here, and has a lot of historical baggage depending on how and when the hardware was designed:
https://en.wikipedia.org/wiki/RS-232

Thanks for everbodys help. I RMA’d the board and expect another one tomorrow.