Strange problem on ttyTHS2 (UART1)

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi, all

as the moderator ‘linuxdev’ has ever mentioned, the device name of UART1(J17) is /dev/ttyTHS2,

but we have encountered a strange problem when conducting the loopback test ~

Our test involved two parts:

i. set UART1 to “9600, 8, n, 1, no-hardware-flow-control”:
J17.PIN4(UART1.RXD) & J17.PIN5(UART1.TXD) are connected together,

and start two shell command windows sh-A and sh-B

in sh-A: type [cat /dev/ttyTHS2]

in sh-B: type [echo -e “1234” > /dev/ttyTHS2] for only ONCE

but, a strange problem occured !! we have received lots of:

1234

1234

1234

1234

…

The line interval between any two adjacent lines of 1234 seems to increase in 2’s exponential,

ii. use the default configuration of UART1, i.e., the default baudrate with hardware flow control,
we connected J17.PIN4(UART1.RXD) & J17.PIN5(UART1.TXD) together
as well as J17.PIN2(UART1.RTS) & J17.PIN6(UART1.CTS) together
and repeat the test method in part i, the same result appeared ~

so, how to fix this problem (a bug ??) ?

BTW, could any one point out the correspondences between the
/dev/ttyTHS* (* = 1, 2, 3) and the hardware ports UART0, UART1, UART2, UART3, and UART7 defined on the interface of
TX2 module

Note: the only difference between our dtb and the default one
is that we have disabled SMMU for PCI-Express, as advised by moderator ‘vidyas’, to
increase the bandwidth of PCIE. The kernel image stays unchanged (R28.1)

2

The ttyTHS# “#” corresponds to the ttyS# “#”…but the THS# version uses the NVIDIA driver with DMA, the S# version uses the ordinary serial driver with 16450 or 16550(A) modes.

You may find this of interest as a test:

sudo -s
find /sys -name '*uart*'
cd /sys/class/tty/ttyTHS2
ls -l device
cd /sys/class/tty/ttyS2
ls -l device
exit

Notice that the “device” symbolic link of ttyTHS2 points to a controller address and appends “.serial”, e.g., “c280000.serial”. Your device tree would use this controller address.

Symbolic link for device of ttyS2 points at “serial8250”…this is a standard 8250 Linux driver. You may find all kinds of instructive relations poking around in “/sys”.

For your testing realize first that serial UART settings may not be what you expect unless you have specifically set those traits. You could be inheriting things you don’t expect.

Also beware that the “newline” character may interact with terminal type settings. An example of an initial setup might work something like this:

minicom -b 115200 -D /dev/ttyTHS2 -8

…then exit minicom and try your experiment.

For me it works. My terminal type settings though may be inherited from my host PC since I am using ssh to connect. How are you connecting to your session…local console terminal…local X GUI terminal…ssh…etc?

3

I believe that the serial device has echo turned on. This would make the string print out over and over.

Further, I believe that the devices does CR and NL translation such that each time it outputs a NL, it outputs a CRNL, and each time it reads a CR, it turns that into an NL, hence the power-of-two increment of number of newlines.

If this is correct, then the device is not broken, it is behaving as per spec.

If you turn off echo and set the device in RAW mode, you will likely see it behave as you expect.

4

Yes, this is an example of inheriting terminal environment…echo and translations seem quite likely to be the culprits because these can be inherited via whatever method of login is used (these are examples of things terminal handling software might add on top of the serial UART…you aren’t really talking directly to the UART, your shell is part of the conversation).

5

thanks，the problem is solved by turning off the echo and ignoring the CR—nl translation～

6

right, shell is the culprits ~

7

That’s not how it works!

That’s only true if you consider the serial port as “terminal handling software.”

In Linux, the serial/terminal driver handles echoing and character translation. Serial ports and terminals (even “ptys” used by network tools like ssh, or shell windows) are “tied at the hip” in the Linux kernel.
Check the man page for termios.h if you want the full details.

The “stty” shell tool lets you change how the tty behaves, too; it controls whichever file descriptor is its “input.”
Thus, you can “sudo stty -echo < /dev/ttyTHS2” to turn off echo for the ttyTHS2 port.
(This works for flow control, baud rate, and all the other attributes of the linux serial/terminal driver, too)

This is why ctrl-S can stop the output of a program inside a ssh terminal – that’s the XOFF control character for software flow control. ctrl-Q is the XON character to resume flow. In my login scripts, I typically turn this off, because I have better uses for the ctrl-S and ctrl-Q characters.
(When you start an editor like Emacs or vim, it will turn the device into raw mode, and turn off these control characters, while running the program – hence, ctrl-X ctrl-S can save in Emacs.)