Jetson TX1 UART1

We need to control an RS-232 port from the Jetson TX1 Development Board. It looked like UART1 is routed to the camera and the J17 6-pin header. We removed the camera. Linux sees one UART (/dev/ttyS0) - is that the Linux UART device that controls J17 (UART1)? When we try to “cat” characters out /dev/ttyS0) we do not see any activity on the Tx (pin 5 of J17). It does not work. Is /dev/ttyS0 controlling J17 UART and if so what do we need to do in order to use this connector as a UART in Linux?

ttyS0 would be the serial console. Note that devices of type “ttyS#” format are ordinary serial ports, but that there is an equivalent on a Jetson…devices of name format “ttyTHS#”. These are serial ports as well, but use a different driver which may have some performance advantages via DMA. Your interest will be basically any ttyS# other than ttyS0, and any ttyTHS#. I have not looked at it for a while, but I think J17 is ttyTHS2 (maybe it is ttyTHS1? not sure).

Thank you so much. We tried to transmit on J17 to a laptop’s RS232 Putty console using /dev/ttyTHS2 and we got garbage on it (at least we got some traffic!). We just ran “cat /etc/hosts > /dev/ttyTHS2”. We were not sure if we got garbage because UART1 appears to get routed to the camera (which we removed) “and” to J17. We set the baud rate to 9600 8N and transmitted to the PC and got garbage. Is this because the J17 header is shared with the camera? Should we be able top copy a string out the J17 connector (/dev/ttyTHS2)? Is this J17 connector RS-232 signaling?

We also noticed UART0 on J21 and we think we need a TTL level translator to connect to our PC’s RS-232 serial port. Is that correct? We have not tried transmitting out this port yet but want an answer on this first. Do we need a TTL to RS-232 level translator on J17 as well?

We just need one RS-232 port on the TX1 dev board to transmit and receive characters to a remote PC’s RS-232 port.

Thanks,
Todd

If the camera is not running (I removed mine for some J17 testing), then there should be no software conflict. In the past I did testing via a USB serial UART which was plugged into the Jetson USB and the J17 side…two minicom terminals were talking back and forth (my favorite though is gtkterm), but I think I had some struggle setting ports correctly. I ended up with 38400 8N1 I think as the default.

What makes life difficult for serial port settings is that the hardware itself is not really plug-n-play…when you make a setting change or query a setting you’re really only talking to the driver…the driver does not necessarily know what the hardware is really doing (such as accepting or ignoring the setting). Having a single serial USB UART connected directly to the Jetson at both ends at least takes away some of the remote host unpredictability, so I’d recommend first using this “loopback” style procedure of the Jetson talking to itself through a ttyUSB# and ttyTHS2.

And you are correct that your UART must be 3.3V TTL level (for both J17 and serial console of J21). The fact that you saw garbage means you are fairly close to succeeding.

Here is info on serial console (hardware is the same as J17 so far as level requirements);
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]

Thank you. We were able to get /dev/ttyS0 working using a TTL to RS-232 signal converter. We could see the Linux debug console and disabled it by removing “console=” from the Linux startup parameters. We were very happy. I don’t think J17 (/dev/ttyTHS2) needs a TTL signal level converter. When we tried copying a file out J21 (using “cat”) with /dev/ttyTHS2 we saw plain characters from our text file but got lots of extra carriage returns and then sometimes the cat would not complete. It was just not really working right. I think we will be ok using ttyS0 (J21 UART0) but still not sure why /dev/ttyTHS2 acts so funny.

There are many cases where noise is an issue. Serial ports were never meant to go fast or far. If you use the CTS/DTS wires for flow control then your reliability will go up significantly. CTS/DTS flow control makes the serial port scale much better to higher speeds. Was your serial console set to CTS/DTS flow control?