TX1 is not booting up No display/response
when i powered it up, i can see 2 LEDs are illuminated, Fan spins for a sec and then stops. No display on HDMI no display keyboard light how to make sure board is fine?
when i powered it up, i can see 2 LEDs are illuminated, Fan spins for a sec and then stops.
No display on HDMI no display keyboard light

how to make sure board is fine?

#1
Posted 02/23/2016 11:57 PM   
Please re-post this question in the proper Jetson T[b]X[/b]1 forum. Thanks!
Please re-post this question in the proper Jetson TX1 forum. Thanks!

Jetson, Autonomous Machines
TK1, TX1 Marketing
EE & Robot Builder
NVIDIA Corporation

#2
Posted 02/24/2016 12:24 AM   
The fan turning off is normal (the fan is throttled back unless heat rises...normally a JTX1 does not need the fan). LEDs should stay on. Keyboard lights should work, but may not be guaranteed if USB or input drivers get in the way. Try the caps lock and num lock; try on a powered HUB. Video is a longer topic. First, if you use any kind of cable which does not support the DDC/EDID channel, the monitor will not work. Basically anything with the older 15-pin D-sub or an adapter for this will not work. Second, information from the monitor is sent to the video of the JTX1 via the DDC/EDID channel. Some information will be sent for older formats from modes which have existed a long time. Extensions will then send more information for newer modes, e.g., hidef 1920x1080. Finally, if your monitor supports the ultra-high-def, this will be sent as yet another extension. The video is supposed to detect oldest modes first, and even if the video is dated, should understand those settings even if newer settings are not understood. It's sort of a fail-safe that if newer extensions are not understood, older settings will be understood. Video data is read under console mode by one driver, and when it gets to the X11 graphics stage, uses different software for parsing of the video data. These packages tend to be independent of each other...one can fail or succeed while the other does the opposite. Console mode (text-only) has a known issue where it may not detect and older monitor's mode, and attempt to scan too fast. The result is the monitor remains black. A newer monitor capable of faster scanning at higher resolutions might work in console mode. Watch carefully to see if the monitor complains about scanning too fast. Booting to graphics mode takes a bit of time, and should then work even if console mode did not...provided that DDC/EDID is readable. What kind of cable do you have on the monitor, including any adapters? FYI, there is a good reason why people have a serial console cable for embedded work...serial console does not require any drivers per se. You can see everything even when video fails. See here for info on serial console: [url]http://elinux.org/Jetson_TX1#Serial_Console_Wiring[/url]
The fan turning off is normal (the fan is throttled back unless heat rises...normally a JTX1 does not need the fan). LEDs should stay on.

Keyboard lights should work, but may not be guaranteed if USB or input drivers get in the way. Try the caps lock and num lock; try on a powered HUB.

Video is a longer topic. First, if you use any kind of cable which does not support the DDC/EDID channel, the monitor will not work. Basically anything with the older 15-pin D-sub or an adapter for this will not work.

Second, information from the monitor is sent to the video of the JTX1 via the DDC/EDID channel. Some information will be sent for older formats from modes which have existed a long time. Extensions will then send more information for newer modes, e.g., hidef 1920x1080. Finally, if your monitor supports the ultra-high-def, this will be sent as yet another extension. The video is supposed to detect oldest modes first, and even if the video is dated, should understand those settings even if newer settings are not understood. It's sort of a fail-safe that if newer extensions are not understood, older settings will be understood.

Video data is read under console mode by one driver, and when it gets to the X11 graphics stage, uses different software for parsing of the video data. These packages tend to be independent of each other...one can fail or succeed while the other does the opposite.

Console mode (text-only) has a known issue where it may not detect and older monitor's mode, and attempt to scan too fast. The result is the monitor remains black. A newer monitor capable of faster scanning at higher resolutions might work in console mode. Watch carefully to see if the monitor complains about scanning too fast.

Booting to graphics mode takes a bit of time, and should then work even if console mode did not...provided that DDC/EDID is readable. What kind of cable do you have on the monitor, including any adapters?

FYI, there is a good reason why people have a serial console cable for embedded work...serial console does not require any drivers per se. You can see everything even when video fails. See here for info on serial console:
http://elinux.org/Jetson_TX1#Serial_Console_Wiring

#3
Posted 02/24/2016 12:31 AM   
Hi linuxdev, I have computer monitor with HDMI input, reflashed board with latest jetpack but problem persist i can see board IP on network but i cant connect to it
Hi linuxdev,
I have computer monitor with HDMI input, reflashed board with latest jetpack but problem persist
i can see board IP on network but i cant connect to it

#4
Posted 02/26/2016 12:32 AM   
How are you trying to connect? Using the dotted decimal format (e.g., like "192.168.1.2", not a name) does not require the same degree of network setup. If ssh fails, what is the fail message? Sometimes cables are also an issue, as JTK1 used an older HDMI standard versus newer JTX1. It may be pickier.
How are you trying to connect? Using the dotted decimal format (e.g., like "192.168.1.2", not a name) does not require the same degree of network setup. If ssh fails, what is the fail message?

Sometimes cables are also an issue, as JTK1 used an older HDMI standard versus newer JTX1. It may be pickier.

#5
Posted 02/26/2016 03:25 AM   
I am using XShell to connect using 192.168.0.10 and port 22, error message is "Not able to connect" I have tried different cables also result is same.
I am using XShell to connect using 192.168.0.10 and port 22, error message is "Not able to connect"

I have tried different cables also result is same.

#6
Posted 02/26/2016 04:12 AM   
I answered in the other thread. I am not familiar with XShell, but if this is running from windows, you probably have other firewall issues. You should just use ssh from Linux, or a serial console...once you establish that things work, then you could figure out what's going on with XShell.
I answered in the other thread. I am not familiar with XShell, but if this is running from windows, you probably have other firewall issues. You should just use ssh from Linux, or a serial console...once you establish that things work, then you could figure out what's going on with XShell.

#7
Posted 02/26/2016 05:05 AM   
Hi I am able to connect serial using a FTDI converter cable, but output is not readable i am using putty with given settings any idea?
Hi I am able to connect serial using a FTDI converter cable, but output is not readable i am using putty with given settings

any idea?

#8
Posted 02/26/2016 06:54 PM   
Can I confirm that settings are speed 115200, 8 bits, no parity, 1 stop bit (115200, 8N1)? Also, is the FTDI cable a 3-pin cable or a 6-pin cable? If 6-pin, can you enable RTS/CTS flow control? For either cable type, once things are on and you are getting the unreadable output, could you disconnect and reconnect the non-USB side of the connector? Then see if it works better. NOTE: Trying to keep this to a single forum thread. Answering from the other thread about ssh refused. The refuse could be because of some security setup issue. Was the ssh from a Linux ssh on command line? Or from some sort of ssh program other than ordinary ssh on command line?
Can I confirm that settings are speed 115200, 8 bits, no parity, 1 stop bit (115200, 8N1)? Also, is the FTDI cable a 3-pin cable or a 6-pin cable? If 6-pin, can you enable RTS/CTS flow control?

For either cable type, once things are on and you are getting the unreadable output, could you disconnect and reconnect the non-USB side of the connector? Then see if it works better.

NOTE: Trying to keep this to a single forum thread. Answering from the other thread about ssh refused. The refuse could be because of some security setup issue. Was the ssh from a Linux ssh on command line? Or from some sort of ssh program other than ordinary ssh on command line?

#9
Posted 02/26/2016 07:04 PM   
Thanks I am using 3 pin cable using this converter [url]http://www.digitus.info/en/products/accessories/adapter-and-converter/r-usb-serial-adapter-usb-20-da-70156/[/url] its FDTI based Tested with 6 Pins also but same result I tried reconnecting but its same, i am using Putty on windows and minicom on linux both has same results. ssh was from Linux
Thanks
I am using 3 pin cable using this converter http://www.digitus.info/en/products/accessories/adapter-and-converter/r-usb-serial-adapter-usb-20-da-70156/ its FDTI based
Tested with 6 Pins also but same result

I tried reconnecting but its same, i am using Putty on windows and minicom on linux both has same results.

ssh was from Linux
Attachments

tx1.JPG

#10
Posted 02/26/2016 08:08 PM   
The output really looks like just a setting issue. Could you try using gtkterm on Linux? Also, are you positive you have the correct serial port selected (USB moves the port each time something plugs in or unplugs...listening to the wrong data stream would certainly be an issue)? Additionally, maybe restart the terminal while the unreadable text is running. If this fails I suspect the particular serial USB UART you are using may be the issue. Serial UART cables are notorious for some brands just not working...perhaps because of I/O voltages being so widely different (FTDI USB chips would not be the problem, but the input to the RS-232 side could be 12V on one system and 5V on another, designs don't always seem to take this into account). The driver at the Jetson side is so simple and basic that it is nearly impossible for the scrambled output to be an issue there...the stream of bytes could be a failure, but the odds are extremely high that this is instead an indicator that the Jetson functions.
The output really looks like just a setting issue. Could you try using gtkterm on Linux? Also, are you positive you have the correct serial port selected (USB moves the port each time something plugs in or unplugs...listening to the wrong data stream would certainly be an issue)? Additionally, maybe restart the terminal while the unreadable text is running.

If this fails I suspect the particular serial USB UART you are using may be the issue. Serial UART cables are notorious for some brands just not working...perhaps because of I/O voltages being so widely different (FTDI USB chips would not be the problem, but the input to the RS-232 side could be 12V on one system and 5V on another, designs don't always seem to take this into account). The driver at the Jetson side is so simple and basic that it is nearly impossible for the scrambled output to be an issue there...the stream of bytes could be a failure, but the odds are extremely high that this is instead an indicator that the Jetson functions.

#11
Posted 02/26/2016 08:52 PM   
Hi You rock :) I bought an USB to TTL, it works like charm, now can you tell me how can i fix the display and shh issue? Any link?
Hi You rock :)

I bought an USB to TTL, it works like charm, now can you tell me how can i fix the display and shh issue?

Any link?

#12
Posted 02/29/2016 01:56 PM   
For display, you said you re-flashed with JetPack. I do not personally have an Ubuntu workstation/host, so I'm not sure of how JetPack configures installs, and in particular the "apply_binaries.sh" step from a manual install is of interest (JetPack must do this, I'm not sure how obvious it is to the end user). Your JetPack should have created a "Linux_for_Tegra" directory somewhere, and "rootfs" within that. If the "rootfs/etc/nv_tegra_release" exists, then apply_binaries.sh was run, and video files would be installed. Can you verify this file exists? Since you have serial console now, from the serial console, do any errors show up from "sudo sha1sum -c /etc/nv_tegra_release"? Or is all ok? Here is an explanation about one HDMI display issue: [url]https://devtalk.nvidia.com/default/topic/917276/jetson-tx1/tx1-hdmi-2-0-interface/post/4808817/#4808817[/url] Can you describe the exact cabling of your video? For ssh, this is possibly just an ordinary ssh setup issue (common for all ssh setup, more common when mixing Windows ssh clients into the mix). Your serial console client should have a logging option, from that could you post the output of "ifconfig"?
For display, you said you re-flashed with JetPack. I do not personally have an Ubuntu workstation/host, so I'm not sure of how JetPack configures installs, and in particular the "apply_binaries.sh" step from a manual install is of interest (JetPack must do this, I'm not sure how obvious it is to the end user). Your JetPack should have created a "Linux_for_Tegra" directory somewhere, and "rootfs" within that. If the "rootfs/etc/nv_tegra_release" exists, then apply_binaries.sh was run, and video files would be installed. Can you verify this file exists? Since you have serial console now, from the serial console, do any errors show up from "sudo sha1sum -c /etc/nv_tegra_release"? Or is all ok?

Here is an explanation about one HDMI display issue:
https://devtalk.nvidia.com/default/topic/917276/jetson-tx1/tx1-hdmi-2-0-interface/post/4808817/#4808817

Can you describe the exact cabling of your video?

For ssh, this is possibly just an ordinary ssh setup issue (common for all ssh setup, more common when mixing Windows ssh clients into the mix). Your serial console client should have a logging option, from that could you post the output of "ifconfig"?

#13
Posted 02/29/2016 08:43 PM   
Hi nv_tegra_release file exist. The hdmi cable i have its A type HDMI
Hi nv_tegra_release file exist.
The hdmi cable i have its A type HDMI

#14
Posted 03/05/2016 12:10 AM   
Does everything respond "ok" if you run: [code]sha1sum -c /etc/nv_tegra_release[/code] During boot, do you ever see any momentary sign of a carrier signal detected, or a note popping up about scan rate?
Does everything respond "ok" if you run:
sha1sum -c /etc/nv_tegra_release


During boot, do you ever see any momentary sign of a carrier signal detected, or a note popping up about scan rate?

#15
Posted 03/05/2016 12:43 AM   
Scroll To Top

Add Reply