i am trying to use the uart ports of the J14 button header (RXD, TXD) of the jetson xavier nx but the problem is that in the documentation i can’t find where are specified the name that ubuntu gives to these port, so i try testing with the 3 available references: ttyTHS0, ttyTHS1 and ttyTHS4 ports, but none port worked, so my question is this UART J14 port is enabled or i have to do the same thing that was done with the jetson tx2 to enable the ttyths2 port?.
may I have your confirmation you’d working with NX or TX2?
for Jetson Xavier NX, it’s pin-3 and pin-4 respectively for UART Receive and Send of J14,
pin-3 and pin-4 were UART2_TXD,UART2_RXD / UART3_TX,UART3_RX =pin 236,238, the port is mapping to ttyTHS2.
here’s similar discussion thread, Topic 145106 for your reference.
I have an Xavier NX Dev kit.
I found this thread on using the UART on the J14 block.
Using pins 3 and 4 for TXD and RXD I connect it to a serial cable to my Windows PC. I have the port settings at 115200,8N,1 but all I get is a bunch of random characters. Everything I’ve read said this should work. I’ve tried other speeds and settings but I’m getting no where.
You should probably start a new topic. However, one reason you might get random characters is if different character sets are used on the two systems. For example, if there is some UTF-16 (two byte) character on one machine, but the other uses UTF-8 (one byte, usually a mirror of ordinary ASCII), then the data will be correct while the display of the data will appear wrong.
Note: You can log in to a Linux system and check the output of “
echo $LANG” to find character set information. Not sure how to do that on Windows.
I had started a new topic last week with zero replies. Thought it was worth a shot to try to post on an existing thread.
I did run across the character set issue on another thread. Checked it all out last week and both sides are UTF8. Since I’m using PuTTY on Windows it is in the “Translation” settings.
Here’s a screen shot of what it looks like.
I see some characters which are one of the Asian characters. I can’t see it close enough to say which, but it appears to be either Mandarin or Korean. These tend to be 16-bit character sets, and I would say there is a strong chance one end is using a UTF-8 character set. This could be coincidental, but something in the data stream does seem to be the wrong character set.
Does PuTTY have the ability to save as binary data? If so, then you could log to a file as binary data, and then post the log. I could then examine the log from Linux and see if this is some other character set.
About the only other possibility is that there is a lot of very bad noise being injected into the wire used for the UART. E.g., a very long wire which is not twisted pair, or an environment with a lot of electrical noise. We already know you are using the correct speed and stop bit and parity settings, but if we did not know this, then the other possibility is a mismatch in settings.
If you could use a serial console from Linux (e.g., just a “live dvd” and not a permanent installation), then comparing that result and seeing the same thing (or something different) would be a good experiment.
Here’s a screenshot of the Xavier env var $LANG.
Screenshot of PuTTY translation:
Not sure about saving binary data from PuTTY. I’d have to look into that.
I did see something about noise in another thread as well. My set up is using jumper wires to an 9-pin serial cable. I did check with another device that I know to be working and it was good. Really bizarre.
did you happen to file the topic at the wrong category? please share the linkage here for reference.
I’ve try the uart communication with Serial Port Utility on the windowsOS, please also have a try to change the utility for verification,
Thanks for the reply Jerry!
I didn’t see a category for “UART” so I picked what I thought would be the most logical “System Managment and Monitoring”. Which is most likely the “wrong” category.
Using the Serial Port Utility I get the same thing…junk :
Your PuTTY is set up for what would normally be correct: UTF-8, 115200 8N1.
I would not expect the boot content of the Jetson itself to be able to use anything but the UTF-8, although once Linux runs this could change to something like a UTF-16 encoding. Is the scrambled content you see showing up instantly (or near instantly) once the NX starts to boot? If there is a short delay, then that content could be from once the Linux kernel loads.
Also, are you certain that the particular COM port is for the Jetson?
One experiment I will recommend (and probably not helping much, but is easy to do) is to tell your serial console program to show hexadecimal. Then boot a few times, and see if the data being presented is (A) the same each time, versus (B) changing. If it is the same each time there might be a way to check it for different encodings.
scrambled content – it looks instant but it’s hard to tell… the only thing I’ve got to go on is the hdmi output
correct COM port – yes it is the correct COM… as I’ve mentioned I used the same cable to another device just to check it is working.
Dumped hex but there is so much data coming thought its hard to tell if it’s the same or different. One thing I noticed with dumping HEX is it’s receiving 0’s constantly. I don’t see this with the text setting.
let’s follow-up your issue here, Jetson Xavier NX UART J14 block