nvidia nx平台UART错误调试

1. 前言

尝试使用Jetson TX2 NX在UART端口
(UART1，引脚203和205，/dev/ttyTHS2)
上通过MAVLink 2协议与ProfiCNC Cube Orange Flight Controller通信，
使用500000波特率
(测试了其他速率，从9600一直到921600)。
软件和硬件已经被验证可以在Jetson Nano上工作，
但是，由于需要一个更强大和性能更好的平台，它被选择采用TX2 NX。

已经更改了TX2 NX上的.dts文件，
以启用UART1端口并禁用所有其他UART接口，因为不需要它们

TX2 NX是运行在一个定制的载板
Tx和Rx线路上的信号在示波器观察,

面临的问题是，当在同一个运营商板上运行相同的软件时
经常会出现超时和数据传输错误
这在TX2 NX上会发生，但在Nano上不会发生

2. 问题梳理

监视“dmesg—follow”，在问题期间能看到任何日志输出吗?
这是一个随机的失败，还是可以重复的?

如果把NX的TX/RX(我假设你没有使用CTS/DTS)放在环回模式
TX和RX直接连接在一起，仍然有数据问题吗?

请共享dmesg日志以获取最终的内核错误或警告。

3. 测试

使用TX和RX引脚上的环回，TX2 NX有可能向UART TX线注入噪声。

3.1 TEST 1

在Jetson Nano和Jetson TX2 NX上测试了一个简单的命令，
echo "hi" > /dev/ttyTHSx.
在Jetson Nano上是ttyTHS1，在TX2 NX上是ttyTHS2。
首先，从TX插入一根电缆到RX引脚，
并向/dev/ttyTHS发送命令
这在终端上产生了无限的垃圾邮件

由于这个串行端口被循环回自身，
下面是运行"hi" > /dev/ttyS1
之后发生的事情

1. echo命令默认在消息的末尾添加一个换行符，因此“hi”+ LF发送到/dev/ttyS1
2. 因为设置了“onlcr”，串行设备将LF转换为CRLF，所以发送Tx线的物理消息是“hi”+ CRLF
3. 因为设置了“icrnl”，所以在Rx线上接收到的物理消息将CR转换为LF。因此，“cat”输出的消息是“hi”+ LFLF。
4. 因为设置了“echo”，所以在Rx(“hi”+ LFLF)上接收到的消息随后被发送回Tx线上。
5. 因为onlcr，“hi”+ LFLF变成了“hi”+ CRLFCRLF。
6. 因为icrnl，“hi”+ CRLFCRLF变成了“hi”+ LFLFLFLF
7. 由于echo的原因，“hi”+ LFLFLFLF被发送出Tx

为了修复这个问题
运行了以下命令:
stty -F /dev/ttyS1 -echo -onlcr

禁用" echo "可防止消息的无限循环，
禁用" onlcr "可防止串行设备在输出时将LF转换为CRLF。
现在，每次运行echo, cat都会收到一个“hi”(带有一个换行符!)
之后，能够通过UART发送单个消息。
在下面的图片中，可以找到已执行的测试的打印:

Jetson Nano (工作正常):

Jetson TX2 NX(它并没有产生无限的垃圾邮件，但它打印了大量的' command not found '):

查看kern.log，
似乎没有任何问题

Note:

在第一次测试中，我们意识到，
如果硬件环回连接在Jetsons关闭时，Jetson Nano将正常启动，
但TX2 NX将无法启动。
我们总是需要拔掉连接，启动TX2 NX，然后再次插入测试。

3.2 TEST 2

使用逻辑分析仪探测这些线
差异是清晰可见的

Jetson Nano:

Jetson TX2 NX:

在Jetson Nano上，可以看到预期的行为，
Jetson在UART行上写“hi”文本，然后静音，
在TX2 NX上写“hi”有一个小的等待，
然后在行上引入更多的数据

4. 使用minicom测试

测试了minicom和结果似乎是一样的，下面的截图:

5. 结论分析

从“命令未找到”的错误开始
如果正在使用一个绑定到串行控制台的串行设备，
那么可能会遇到这种情况
(或者如果意外地使用了一个有效的命令，例如“ls”，那么可能会返回一些意想不到的信息)。

“/dev”中的设备不是真正的文件，
实际上是假装成文件的内核驱动程序
(普通的文件读/写操作，结合IOCTL调用，使内核驱动程序可以像文件一样工作)

当且仅当“#”相同时，可以预期任何“/dev/ttyTHS#”与
相应的“/dev/ttyTHS#”是完全相同的UART硬件

不应该同时使用两个驱动程序，
如果与一个将ttyS绑定到串行控制台的ttyTHS对话，
那么这正是会发生的事情。

使用ttyS用于串行控制台的原因是，
早期的引导代码(在Linux内核运行之前)
只有遗留驱动程序，不具备使用支持dma的ttyTHS驱动程序的能力。
在引导期间，如果从一个ttyS切换到一个ttyTHS，串行控制台日志的连续性将会丢失，因此串行控制台都使用ttyS。

如果运行这个命令，那么任何带有“dialout”的“group”都只是一个串行UART，
但是带有“tty”的“group”都将用于串行控制台:
ls -l /dev/ttyS /dev/ttyTHS

另外注意，不同的tty可以用于不同的Jetson设备上的串行控制台。
UART是否有任何意外使用，它也是一个控制台?

供参考，UART设置的控制最初是通过设备树进行的。
针对特定设备的PINMUX电子表格是你设置不同默认值的方式。
然而，使用这个作为串行控制台的软件是一个独立的答案……
在U-Boot中可能需要做一个改变，Linux本身也需要做另一个改变。
关于禁用或更改串行控制台以使给定端口可用
(如果串行控制台不使用该端口，那么答案就更简单了)，