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.
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.
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).
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.