485和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控制管脚的电平，只看到了两者是反向的，但是并没有放大去看最后一段电平的细节。导致遗漏了解决问题的线索。
一切问题发生都是有原因的。偶现问题并不好排查，但是我们可以尝试制作偶现问题发生的条件，看有没有可能成为必现问题。如果不能必现，可尝试通过脚本去不断运行在问题发生的场景，使其出现的概率提升。
心态。放平心态，多看代码。认真分析。
激光视觉焊缝跟踪在压力容器焊接
CMEF2018春季展：深睿医疗告诉你AI+医疗是怎样的体验
万用表测电容没反应怎么回事
消费类音视频SoC系统ATE测试要求
华为正式启动了一口价换电池服务
485和MCU通信通信异常故障分析
小派科技着手建设生态，2022GDC荣耀回归
tslib库编译与移植
优傲机器人简单操作及PolyScope软件系统介绍
三星Galaxy S8行货开卖时间曝光：5月10日
无刷电机和永磁电机有什么区别
同线电话转接装置制作,Call forwarding
物联网产业的国际新标准
dfrobotI2C LCD1602 液晶显示屏简介
DS18S20-PAR 寄生供电数字温度计
TDK小型低输出无线供电系统的特点
通用型高压带关断功能的单通道运算放大器——AXOP36061S
单片机I/O的常用驱动和隔离电路的设计方法
实用|室外光缆怎么接详细步骤来啦
嵌入式C语言的指针、函数概念、结构体递归三大挑战
前段时间接到一个项目，要求用主控用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控制管脚的电平，只看到了两者是反向的，但是并没有放大去看最后一段电平的细节。导致遗漏了解决问题的线索。
一切问题发生都是有原因的。偶现问题并不好排查，但是我们可以尝试制作偶现问题发生的条件，看有没有可能成为必现问题。如果不能必现，可尝试通过脚本去不断运行在问题发生的场景，使其出现的概率提升。
心态。放平心态，多看代码。认真分析。
激光视觉焊缝跟踪在压力容器焊接
CMEF2018春季展：深睿医疗告诉你AI+医疗是怎样的体验
万用表测电容没反应怎么回事
消费类音视频SoC系统ATE测试要求
华为正式启动了一口价换电池服务
485和MCU通信通信异常故障分析
小派科技着手建设生态，2022GDC荣耀回归
tslib库编译与移植
优傲机器人简单操作及PolyScope软件系统介绍
三星Galaxy S8行货开卖时间曝光：5月10日
无刷电机和永磁电机有什么区别
同线电话转接装置制作,Call forwarding
物联网产业的国际新标准
dfrobotI2C LCD1602 液晶显示屏简介
DS18S20-PAR 寄生供电数字温度计
TDK小型低输出无线供电系统的特点
通用型高压带关断功能的单通道运算放大器——AXOP36061S
单片机I/O的常用驱动和隔离电路的设计方法
实用|室外光缆怎么接详细步骤来啦
嵌入式C语言的指针、函数概念、结构体递归三大挑战