Linux 485驱动通信异常

背景

前段时间接到一个项目,要求用主控用485和MCU通信。将代码调试好之后,验证没问题就发给测试了。测试测的也没问题。

但是,到设备量产时,发现有几台设备功能异常。将设备拿回来排查,发现是485通信有问题,偶现通信失败。

排查思路

复现问题

发给测试之前,功能都验证了很多次,但是并没有发现通信失败的问题。设备拿到手,第一时间就尝试复现通信失败的问题,也没有成功。

于是,写了一个脚本,不断的和MCU通信,看什么情况下会失败。

果然,在通信若干次后,发现日志异常,主控接收数据出现了错乱。

接着,继续跑脚本,想看下什么情况下会失败。但是,每次通信异常的时机都是随机的,没有规律。

观察了下错乱的数据,和正确的数据做了对比,也没有什么发现。

清空buf

接收的数据出现了异常,第一个想到的是,是不是接收buffer不干净,有其他数据干扰呢?

尝试在接收buffer和发送buffer之前,手动清空下buf。确保不会有其它数据干扰。

重新跑脚本和MCU 通信,但是仍会失败。

收发时序

光看是什么办法了。上示波器看下主控和MCU的时序的。

正常来讲,主控和MCU的485控制管脚应该是正好反向的电平。即主控485控制管脚高电平发送的时候,MCU的485控制管脚应该是低电平。

问题复现时,对比了管脚的电平,确实是反向的,没有问题。这也排除了收发时序对不上的问题。

(绿色的是MCU的485控制管脚,黄色的是主控的485控制管脚)

收发数据正确

小示波器没有解码的功能,只能找硬件来量下主控的RX和MCU的TX。确认下,到底是主控接收的不对,还是MCU发的不对。

显然,是主控接收的数据有问题了。

仔细观察会发现,绿色波形这里有个半高电平,覆盖了黄色的低电平。导致第一帧出错了,后面的数据也都错乱了。

又重新复现了几次,发现每次失败时都是这种现象。那为什么这里会有个半高电平呢?

确认问题

和硬件对着原理图经过一番讨论,硬件给到的结论是,485芯片的RX管脚接了3.3V的上拉,只有当485芯片的使能管脚拉高时,RX才会有3.3V的半高电平出现。硬件怀疑是485控制管脚和MCU的时序没对上。

不过,我之前也量了主控和MCU的485控制管脚的电平,看了是对的?难道是我看错了?

接着又重新量了主控和MCU的485控制管脚,发现确实有问题,具体如下图。两者有1.5ms的高电平是重合的,这或许就是问题所在!

又重新复现了几次问题,发现每次通信失败时,都会有一段高电平是重合的。

到这里,基本也就明确了问题原因:主控和MCU的485控制管脚时序没对上

寻找问题根因

从波形找出了问题所在,回归串口编程,继续看下代码吧。把重点放在了时序切换的代码上。

代码里面,在切换485管脚时有这样两段代码。

以下只是伪代码

代码一:

c 复制代码
setdir(SEND)		//切换为发送状态
write()				//发送数据
tcdrain(fd) 		//判断是否写完
setdir(READ)		//切换为读状态

代码二:

c 复制代码
do
{
	ioctl(fd,TIOCSERGETLSR,&lsr)	//判断发送buffer是否写完
}while(!(lsr&TIOCSER_TEMT))	//如果TX为空,返回TIOCSER_TEMT

这两段代码,都是和485管脚切换相关的,根据不同情况走不同逻辑,出问题的代码走的是代码一片段。

tcdrain 和 TIOCSERGETLSR

那这两段代码有什么区别呢?

tcdrain是应用层控制tty的一个函数,调用 tcdrain()函数后会使得应用程序阻塞, 直到串口输出缓冲区中的数据全部发送完毕为止。

ioctl(fd,TIOCSERGETLSR,&lsr)是获取tty 设备的线路状态寄存器( LSR )的值。

这两段代码最大区别就是延时不同!

tcdrain()是等待fd所引用的串口设备数据传输完毕。虽然在物理上数据已传输完毕时,但Linux对硬件实时性高,对于用户请求的实时性较低 。所以操作系统会有延时,导致tcdrain()多停留几ms,从而导致数据发送完后,485管脚的控制方向不能及时切换

如果对接的485设备,接收和应答的延迟小于tcdrain()的延时,那方向切换不及时将导致数据接收丢失。这就是问题根因所在。

那为什么操作系统会有延时呢?

这个得说说Linux工作队列相关机制,对于硬件操作Linux处理的很及时,但是对于数据Linux可能将其交给系统的下半部的内核线程去处理,这就可能导致用户的系统调用存在一定的延时,而485通信对时间要求又很严格,1ms的延时就会导致数据错乱。

总结

  1. 严谨细致。在问题发生时,我也去量过主控和和MCU 485控制管脚的电平,只看到了两者是反向的,但是并没有放大去看最后一段电平的细节。导致遗漏了解决问题的线索。
  2. 一切问题发生都是有原因的。偶现问题并不好排查,但是我们可以尝试制作偶现问题发生的条件,看有没有可能成为必现问题。如果不能必现,可尝试通过脚本去不断运行在问题发生的场景,使其出现的概率提升。
  3. 心态。放平心态,多看代码。认真分析。