I have Jetson TX2 mounted on Orbitty carrier board, and i experienced strange problems with UART0 (which device file is ttyS0). I changed Jetpack and half disabled/half transferred serial console from this port to UART1. When i try to send some data packages using syscalls (port configured with termios, raw mode enabled) they arrive to destination. But when i try to receive responses, package is always shorter then expected and contains really strange data (like 3 bytes with values 0x02 0x04 0x08 several times in package). When i try to connect to UART line from my laptop using USB-UART converter and try to comminicate with device using same software - it works. When i using picocom on jetson and on my laptop connected to line - it works. What can be the problem here?
Your settings at both sides of the connection must be the same, e.g., both 115200 8N1 without flow control. An example of one failure possibility is that if one side has a different concept of stop bits versus the other side of the communications, then you might get incorrect interpretation of bytes.
Settings on the both side of the bus are the same. I actually mentioned that Jetson do transmission right, but has this problems with receiving, and i tried the same software on my laptop instead of Jetson and receiving worked fine (checksum was right, bytes was the same).
One of the difficulties of working with UARTs is that UARTs do not report their current settings. Any query is really a query of the driver and not the hardware. If a driver is told to use a setting the hardware does not support, then the driver will happily say the current settings are correct despite being something impossible for the hardware. I suspect that a setting is not really what you think it is. The software which is using the data may be doing some sort of serial interpretation which you don’t expect.
So far as the device which sends data to the Jetson is concerned, how do you control its settings? It sounds like the speed is correct, otherwise output would be complete garbage. Receiving a message which is too short makes me think the sender is sending fewer bits than expected, or conversely, that the receiver is thinking some data bit is really for control and is truncating. If you have a protocol analyzer you might be able to see this directly. If you have an oscilloscope and can send a repeating pattern, e.g., 0x1 or 0xe (both values have a single “1” bit…an oscilloscope could watch the pattern repeat if done correctly, or slowly drift across the screen if a bit is being truncated).
The device sending information to Jetson is MCU, and i control its UART settings directly. They are right too, because when i connecting to the same bus when Jetson powered off with my laptop under Ubuntu with the same software (i mean exactly same program which i wrote) i use on Jetson - it works. MCU receives messages correct too (first byte, length and checksum correct), and sends correct messages back. Timings are good and i clearly can see data packages that don’t drift away in time, logic levels and noises are ok (used oscilloscope to check the bus).
So maybe i don’t know something about special Jetson UART drivers? But where can i get more information about them and why such primitive tools as syscalls and termios don’t work as expected?
Most of what you are asking about is in the Linux kernel itself. The drivers with “t186” or “t18x” refer to the TX2. Some of the base code is unchanged from other devices though, so some code from other Tegra platforms might be mixed in. The “hs” variant is the DMA version when using the “/dev/ttyTHS*” device instead of the “/dev/ttyS#” devices.
If you have the “source_sync.sh” script, which comes with the driver package for flashing (which in turn is automatically downloaded if you ever flashed with JetPack), then you can get the full source via this (I am assuming R28.2.1, adjust for your case):
./source_sync.sh -k tegra-l4t-r28.2.1
Since you have been using “ttyS0” this is not the “HS” high speed UART driver, it is just the 8250/16550A. Do beware that if for any reason some part of the system is still mixing in serial console then it is possible you are just seeing the shell’s response to what it sees as nonsense.
I tend to verify with loopback (tying RX and TX together…if flow control is used, then also typing CTS and RTS together) first, with power still connected and settings not changed followed by reconnect of the actual serial connection. If the serial console (my favorite gtkterm) echoes correctly at a given setting, and then talks to the other device with something odd going on, then it likely is not a fault of the TX2. If you do this and the TX2 injects something unexpected, then chances are it is because the serial console is still partially active.