Through the /dev/ttyTHS2,I use the RS422 in my TX2 to send the message to singlechip(ATmega128) continuously,But occasionally it will be blocked and the process is destoryed , and it always works well in the beginning of the process。
I’ve not worked with RS422. However, for any UART I suspect that some of the desired qualities don’t care about protocol and only care about UART qualities. To that end, just speculating, what speed is being used? How many stop bits? What is the length of wiring? Is it quality twisted pair wiring?
Note that speeds above 115200 require two stop bits.
As speed goes up higher you’ll find not overrunning/underrunning the buffer improves with CTS/RTS flow control (versus no flow control, i.e., versus software flow control).
Also, monitor “dmesg --follow” before starting things and watch if there is a debug message when something goes wrong.
Just speed 9600 baud，One stopbits and no flow control .The wiring is well quality. monitor “dmesg --follow” ,For a while,it says “RxData DMA copy to tty layer failed”,But I still can receive the message from /dev/ttyTH2 correctly.When I CTRL+C to quit and run it again ,it works well again.
It’s interesting because DMA works with “high speed” drivers (the NVIDIA driver), but not with the regular UART driver. Can the ttyTHS2 test which does this be tested in loopback? You’d just want to wire the TX and RX together and it should be enough since you don’t use flow control.
Just some history which might help later: Most modern UARTs are typically 16550a or compatible. The UARTs on the Jetson are capable of this mode, but are also capable of using DMA. When the regular driver is used the result would be “ttyS2” name syntax, but when using DMA with the NVIDIA version of the driver the syntax would show “ttyTHS2”. Serial console purposely skips “ttyTHS0” and uses “ttyS0” in order to not need reinitializing the UART when transitioning from U-Boot to Linux…U-Boot does not have the DMA-capable driver. Whenever you see both “ttyTHS2” and “ttyS2” only one should actually be used (it’s probably a bad idea to have two drivers using the same device at the same time). Since DMA is mentioned I’m wondering if it is a simple setup issue.
When I disconnected the serial port with the other devices and only test in lookback，it works well for a long time. Once I connect with my PTZ ,The fault occurs again，This seems to be the external signal interference to the serial port and cause the RS422 of TX2 stopping working，why ？Thank you for your patience.
And there is another feature, once it works well for a long time ,it can works well forever in this process
The default I believe is 3.3V TTL logic level. In some cases it may be 1.8V. If possible, first verify the device being connected is 3.3V logic level.
Often if gibberish occurs, then there is an incompatible setting between the two ends, e.g., speed or stop bits, so on. The beautiful thing about loopback is that you know when a device talks to itself both ends agree on the settings :P Making sure that the loopback setting which worked on the Jetson matches on the end device is a different story. Be sure the end device uses the same settings, including any flow control and stop bits.
After a few days of testing, I found some clues 4. when I output constants from the serial port,it works well anytime.when I store variables in an array and output them,it occasionally stops working ,then open the /proc/PID/status,it writes futex_wait_quene_me and turns to wait_woken in the end. In /proc/PID/stack,it writes 98 0X4b16c4…… ，and
subsequently turns to 64 0x5 0x7fd…….In unistd.h,98 is defined __NR_futex,64 is defined __NR_write. Is there useful clues to solve the problem? Thank you for your patience.
How is the data being sent? Is this an interpreted language? I’ve actually had something similar occur in bash scripts when data was not correctly escaped (e.g., a “>” redirect is in data not sent as data, but instead causing a redirect in where data goes). This would of course not be an issue if it is a compiled language like C or C++.
Unfortunately its C++… Too much headache
I actually prefer C++. Regardless, do you have a way to know which specific characters it fails at? What I’m wondering is if there is some special character or combination involved. How much control do you have over the other end? My thoughts are perhaps if the other end has an echo mode you could test just echoing back (the next step after loopback…compare what went out with what came back, see if this results in lockup if you have that option).
Have you tried with performance maxed out? I ask because perhaps there is a time delay in DMA causing the error, and there may be competition for CPU core 0. To force max performance:
sudo nvpmodel -m 0
sudo ~nvidia/jetson_clocks.sh
# Fan will max out, but if you want it to remain <i>automatic</i>:
sudo echo 0 > /sys/kernel/debug/tegra_fan/target_pwm
Would someone from NVIDIA have some insight on this error message:
RxData DMA copy to tty layer failed