Basic functionality glitches with Jetson TX2 Development Kit and JetPack 3.1

I have a Jetson TX2 Development Kit running JetPack 3.1 and have not updated Ubuntu; only NVIDIA Redtail is installed.

Here are magical issues that bug me:

  • If I plug in an HDMI to DVI cable to connect the Jetson to a monitor and turn on the Jetson, it won't display. I have to unplug the cable, turn on the Jetson, wait 10 seconds and then plug in the cable for the monitor to work.
  • If I have the Jetson serving as basic wireless access point with a password, as soon as I plug in an ethernet cable, the Wi-Fi will shut off, and the HDMI monitor will shut off. Then, if I unplug the HDMI cable and plug it back in, the monitor will turn back on.
  • If I connect a PixHawk via UART and turn on the Jetson, the Wi-Fi access point will never become available.
  • If I connect a PixHawk via UART after the Jetson is already running, the Wi-Fi will shut off.

I just placed an order for a serial cable so I can start debugging. What is a good strategy to debug this? For example, should I turn on any specific logging capabilities?

NetworkManager can be quite irritating, and has the same issues on desktop Linux and any other Linux system. I suspect getting networking to do what you want (where WiFi has issues) is a case of learning things about network setup in Linux under NetworkManager (things you probably never wanted to learn…I simply edit files and ignore NetworkManager). That part isn’t something specific to a Jetson.

If you use the UART on J21 (I am assuming you use the dev carrier board), then this will cause all kinds of issues because it is set up as a serial console and U-Boot listens to any activity before Linux ever starts loading. Any activity on this port should be avoided unless you have disabled serial console in both Linux and in U-Boot.

Running “dmesg --follow” from serial console and seeing what shows up as issues arise is the place to start.

For HDMI there are some issues with 4k modes (is this a 4k monitor?), but otherwise it should be ok with most modes. Verify that you get EDID data:

sudo -s
cat `find /sys -name edid`
exit

…not all HDMI-to-DVI adapters pass this data through. Without EDID data automatic configuration can’t succeed. If this does work, paste it into http://www.edidreader.com and see if the checksum is valid.

If checksum is valid, check out “/var/log/Xorg.0.log” to see what it says about errors. You may want to add this to increase logging (add to Section “Device” in “/etc/X11/xorg.conf”):

Option   "ModeDebug"

…this will tell you about modes which are accepted or rejected, and if rejected will tell something about why the mode was rejected.

Thanks for the reply. The NetworkManager culprit makes sense, and I think I can live with HDMI as is. However, the serial console situation I have to deal with. If I want to keep the UART0_TX & UART0_RX (pins 8 & 10 on J21) dedicated for serial console use, how do I connect a PixHawk? Most examples online show how to connect a PixHawk’s TELEM 2 to a Auvidea J120 carrier board’s UART2 RX/TX pins. I’m not sure how to get another 2 pins on the Jetson TX2 Development Kit dedicated to UART2 through some /dev/ttyTHS*.

J17 is physically routed to the camera. If you are not using the serial UART to the camera socket (such as for controlling a camera), then you can use this ("/dev/ttyTHS2"). This port (by default) works as an ordinary serial UART…no device tree changes are needed, it should “just work”. The primary issue will be if you need faster communications than from the default 115200 8N1…in which case you may have some work ahead of you.

Thanks again! I got the PixHawk wired to the J17 and it was already configured to use a baud rate of 921,600 per the Redtail wiki instructions. I’m seeing “serial-tegra c280000.serial: configured rate out of supported range by -1.18 %”, so I’ll try dropping the rate to 115,200 and see what happens.

So, it turns out that the PixHawk only works with a companion computer at either 57,600 or 921,600. If I manually change it to 115,200, the PixHawk doesn’t work. I tried setting the PixHawk to 57,600 and then testing it with mavproxy and got some interesting output.

root@tegra-ubuntu:~# mavproxy.py --master=/dev/ttyTHS2 --baudrate 57600 --aircraft MyCopter
Connect /dev/ttyTHS2 source_system=255
[ 402.214114] serial-tegra c280000.serial: configured rate out of supported range by -0.6 %
no script MyCopter/mavinit.scr
Log Directory: MyCopter/logs/2016-02-11/flight17
Telemetry log: MyCopter/logs/2016-02-11/flight17/flight.tlog
Waiting for heartbeat from /dev/ttyTHS2
l;Y=U<AEB% I(sL/MAV> K@g<</?B29:,RMxg<<.?5mZ:l-:?Og<Z<-?OP:qO8f:wZonline system 1
MANUAL> Mode MANUAL
=G8L<:EBQ )fence breach
RYg<<4?PD{:@99??FW_MAN_Y_SC >ULNDMC_FFALL_TTRI Te<<;0?xx_x9G=lLPE_PN_P9RCL_ACTV=’"<=EBwQ’9HCMPC_MAN_Y_MAX "s~PWM_MAIN_REV4TvDg<w <a?t&8H<UDRC6_MAX %COzhh<<?U\9%?p800’ iP#iM!>
#?hX%k?CAL_ACC1_ZOFF\kb90w:`T5_VTi0G!>R;+cz=>BEkMn
M=1:><=EB
:zN:h<7h<T4:@h<<d?T*:;8sG9DaiReceived 446 parameters
Saved 447 parameters to MyCopter/logs/2016-02-11/flight17/mav.parm

Two things of interest…

(1) [ 402.214114] serial-tegra c280000.serial: configured rate out of supported range by -0.6 %

That error goes away when I set the PixHawk to 115,200, but I get no response from the PixHawk either (cause it doesn’t support 115,200). I need that error to go away when using 57,600.

(2) There are several human readable words in the output (ex. MANUAL> Mode MANUAL), so the PixHawk seems to be working.

I tried using “setserial /dev/ttyTHS2 baud_base 57600” before running mavproxy.

So, can you please elaborate more on “in which case you may have some work ahead of you”? I don’t need that camera that came with the dev kit, because I’m using a USB camera. I just need the baud rate to be changed on the Jetson to one compatible with the PixHawk.

I started using “stty -F /dev/ttyTHS2 921600” instead of “setserial”. I noticed that when I connect my laptop to Jetson via serial console, I get the “serial: configured rate out of supported range by” error. However, if I connect to the Jetson via Wi-Fi access point and run the command in a terminal, I don’t get the error. Interestingly enough, the 5 volt power from the J21 ends up not being enough for me to arm the PixHawk (even though it powers it). When I connect a battery and a UBEC to power the PixHawk, the low power error goes away and it arms, but crazy characters start showing up in the terminal. When I plug in an additional ground cable to the Jetson along with the ground cable to the UBEC, the junk characters stop appearing. I think I’m going to try soldering and shielding better to see if that helps with the garbage characters that are appearing in the terminal.

I do have mavros seemingly connecting to PixHawk, and the Redtail software looks like it is running. So, I’m fairly happy at the moment. I’m about at that point where “hello world” works and code hacking begins.

If you run at 57600 there shouldn’t be any issue. When you run faster than 115200 you probably need to be careful about wiring (e.g., twisted pair on the TX/RX or CTS/RTS, and outer shielding), and perhaps use flow control.

The way I’ve come to test is to initially use loopback. I wire TX and RX together on J17, then CTS and RTS are also wired. This makes J17 talk to itself…any terminal program should echo text correctly. Default is 115200 8N1, software flow control.

I then enable CTS/RTS flow control (various terminal programs might not expect naming convention ttyTHS2…I save serial terminal program configurations to a file and then edit the config file so I can quick switch configurations when testing…mostly I use gtkterm). Typing in to the terminal should still echo.

Next you can switch gtkterm (or minicom or whatever you use) to 57600, 8N1 (CTS/RTS if you are using flow control…this is a good thing to use if you expect to run faster data rates or longer cables).

To change the setting on command line (quite useful if your terminal program doesn’t understand that speed) using CTS/RTS hardware flow control:

stty crtscts 921600 </dev/ttyTHS2

…verify:

stty -F /dev/ttyTHS2

…also set your terminal program to this and see if echo works without corruption.

Just to emphasize, best practice would be to use twisted pair on the TX/RX wires. Use twisted pair on CTS/RTS with a slightly different twist pitch versus the TX/RX. Use an outer shielding around this. This won’t matter on very short wires, but at 921600 you might get corruption in a noisy environment or with long cables. Test everything initially at the slower 57600.