Can /dev/ttyTHS1 work at 460800bps?

Hi,

We connected a serial device @ 460800bps to /dev/ttyTHS1, got this warning/error:

“configured rate out of supported range by -0.29%” and some

“RxData DMA copy to tty layer failed”.

And the data received were not correct.

I wonder if TX2 can work at 460800bps and how to solve this problem if possible.

Thanks.

I don’t know if that rate is supported, but if it is, you would very likely hardware flow control via CTS/RTS would help. If you are using software flow control this would very likely be a problem even if settings are otherwise valid.

Hi linuxdev,

Thank you for the reply.The module we connected to TX2 doesn’t provide HW flow control signals and it worked well with TX1 before.

After some diagnostics, we found TX2’s two stop bits mode might be the reason.

We use a xsens module which in 8N2 mode (not sure if the module truly use 2 stop bits, but its SDK uses this mode and the module works well with TX1’s 8N2 setting), however, TX2 got lots of 0x00s between some none-zero data. If I set the TX2 in 8N1 mode, it seemed work.

As it works for us at least for test purpose, I needn’t dig into the true reason for now. It would be nice if nvidia can see into this problem.

hello ZhangXin,

may i have your confirmation that you’re able to work with 8N1@460800 ?
may i know which serial port you’re using ? which JetPack version ?
thanks

Hi JerryChang,

Yes, the xsens module works with 8N1@460800bps but not with 8N2 as the module should. We use /dev/ttyTHS1 and JetPack 3.1. We built the R28.1 kernel (4.4.38)by ourselves without modifying the serial driver(tegra-serial.c).

This configuration works:

stty -F /dev/ttyTHS1 -a
speed 460800 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

But this not:

stty -F /dev/ttyTHS1 -a
speed 460800 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

And the difference is just the “cstopb”.

Hi JerryChang,

I had some tests with a PC and found that the phenomenon was similar to the above when PC sent in 8N1 and TX2 received in 8N2. So I checked the xsens module with oscilloscope, and it worked in 8N1 in fact. As the code (8N2) worked well with TX1 and xsens SDK used 8N2 as the default setting, I thought the module worked in 8N2. So the TX2’s ttyTHS1 should be good.

However, I found “1 = Transmit 2 stop bits (receiver always checks for 1 stop bit)” in “PARKER | TRM | DP-07281-001_v1.0p”, so maybe this feature of TX2’s serial receiver doesn’t work? Maybe TX1’s receiver meets the description, so it seems more tolerant than TX2.