Serial sonsole port received garbled text


I used Jetson Xavier NX Devkit, and standard Jetpack 4.4(R32.4.3), when directly using console pin “UART RXD” and “UART TXD” from carrier board, I got garbled text from my host PC by using “picocom -b 115200 /dev/ttyUSB0”.

The same result even occurred in windows system, and I changed 2 USB to RS232 cable, but the problem also happened, so cable issue should be ignored.

Could you please help provide recommendation to resolve the issue.

Thanks a lot.

By the way, I used “Jetson Xavier NX P3668-0000” and “Jetson Xavier NX P3668-0001” on same carrier board (dev kit), but I got same result.

I don’t have picoterm, but the speed is correct. Is the default set for 1 stop bit and no parity? If those are off it can misinterpret which parts are data versus control.

One other possibility, perhaps a bit more rare, is if the character encoding is different between the two systems. For example, if individual characters are 8-bit (such as “echo $LANG” returning the common “un_US.UTF-8”), while the other system is using a UTF-16 (or even just a very different character set with UTF-8), then the data transfer will actually be valid, but data will appear differently due to splitting two bytes into a single byte.

A very good way to test is loopback. If you connect RX to TX directly on the Jetson without the remote end being connected, then typing characters should always return correctly since a UART will always agree with itself on details such as flow control, stop bits, and character encoding. If the UART works with loopback at both sides, and if at both ends the same encoding is used, then any scrambling will be for some other hardware reason.

One hardware reason if if cable lengths are long. Longer lengths tend to require twisted pair. Longer than that also tends to require shielding. I like using ethernet wire for anything beyond a short run. Even on a short run with loose wires I like to manually turn this into twisted pair.

Hi linuxdev,

Thanks for your suggestion.

I tested the loopback method, as pin “UART RXD” and “UART TXD” from carrier board -> RS232 to USB cable -> USB port on Jetson Xavier NX Devkit.

I still installed “picocom” on NX Devkit, and used command “picocom -b 115200 /dev/ttyUSB0”.

I saw the stop bit was"1" and parity was “none” in setting, but the terminal still showed garbled text if I typed from my keyboard.

Is there any misunderstanding from me? Thanks.

This looks like a problem on the NX side. Loopback should not do this. I suppose there may be some strange method of setting RX and TX differently, but I do not know of such a method. Certainly the simple startup of picoterm should be valid just as you’ve used it.

Wherever you started picoterm, if you first run the command “echo $LANG”, what do you see? I am assuming it is something with “UTF-8”. If one side of a terminal uses 8-bit characters, and the other side uses some other character size, then you will get bit shifting based on the difference (e.g., mixing UTF-8 and UTF-16` would result in an “off by one byte” each time). I believe that under loopback you could not have a character size difference/shift. The interpretation of that character could change, though highly unlikely in loopback.

If $LANG says you are using “en_US” at one end, and something other than “en_US” at the other end, then the data sent would be valid and not scrambled, but the display of how the character is interpreted would indeed look scrambled. This seems unlikely in loopback mode.

If there is a bit being dropped or appended, e.g., due to one side making an incorrect assumption about stop/start bits, then there would be a bit shift at each character. This also seems unlikely in loopback, but it is worth testing.

I will assume your “$LANG” is an 8-bit character (such as from “UTF-8”). In that case the letter “U” has binary value “01010101”. The UTF-8 character “ª” (which is an odd character which won’t render correctly in normal situations) has binary value “10101010”. Note that this is a single bit shift of “U”. If you are typing in text on your loopback terminal, and you repeatedly type in the character “U” (capital U), does the garbled text alternate back and forth between correctly showing “U” and then nonsense? Or is all text nonsense?

Does your picoterm have the ability to display hex? If so, then displaying hex (or even binary) allows you to see patterns in bit shifting (versus random corruption) when the input is a repeating bit pattern.

One other bonus of the loopback is that it doesn’t use long wires, so environmental electrical noise won’t be the issue even if there is some sort of corruption, so you can assume the wiring is not an issue (at least under loopback).

Hi linuxdev,

Thanks for your big help. I excluded the concern mentioned by you and found the root cause.

I changed cable to “TTL to USB”, then console displayed correctly, and string could be typed through keyboard.


Sounds like the cable was not for 3.3V TTL, and may have been partially functional at the wrong voltage.