控制/MCU
背景
前段时间接到一个项目,要求用主控用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管脚时有这样两段代码。
以下只是伪代码
代码一:
setdir(SEND) //切换为发送状态 write() //发送数据 tcdrain(fd) //判断是否写完 setdir(READ) //切换为读状态
代码二:
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的延时就会导致数据错乱。
总结
严谨细致。在问题发生时,我也去量过主控和和MCU 485控制管脚的电平,只看到了两者是反向的,但是并没有放大去看最后一段电平的细节。导致遗漏了解决问题的线索。
一切问题发生都是有原因的。偶现问题并不好排查,但是我们可以尝试制作偶现问题发生的条件,看有没有可能成为必现问题。如果不能必现,可尝试通过脚本去不断运行在问题发生的场景,使其出现的概率提升。
心态。放平心态,多看代码。认真分析。
审核编辑:黄飞
全部0条评论
快来发表一下你的评论吧 !