原创 关于串口复用造成的意外及总结

问题：

串口复用导致备用串口接收上一直有低电平信号产生，程序中两个串口中断共用同一个数据接收处理标识，造成数据接收的干扰。

 

前两天测试人员发现，在测试运行的产品中，有两个运行不正常。于是对出现异常的产品进行了重点检测。

开始怀疑是产品中的无线模块信号不好，造成一段时间后就连接断掉。于是使用了一个测试好用的无线模块，测试发现测试产品运行效果和原来一样，还是比较异常。而且观察产品的数据通信指示灯，感觉闪灯很不正常。没有数据交互的情况下，485通讯指示灯经常闪烁。而且无线模块通讯指示灯反而长时间没有点亮。为了验证闪烁的LED确实是485通讯指示灯，选择了运行正常的产品，但是等了很长时间发现不容易观察到现象。于是选择了看代码，查电路图。根据电路图及代码指示，闪烁的LED确实是485通讯指示灯。

但是，这样问题就来了，为什么485通讯指示灯，在没有数据交互的情况下会点亮？

将正在运行的程序版本从SVN中导出，进行在线调试。发现在没有数据交互的情况下，程序一直进入485数据接收处理代码。这样在程序上验证了，闪灯的确实是485通讯指示灯。也就说明485串口上有异常数据被接收。但是，此时使用示波器，在485的串口接收端口上测试没有发现电平有变化。使用断点调试发现，确实是485的数据接收处理函数被调用，进行485数据的处理。于是在485数据接收超时回调的函数部分设置断点。程序确实进入到超时回调函数中。但是，485串口接收引脚很稳定，没有电平变化。于是将断点设置在485串口接收中断中，发现程序没有进入这个中断，但是超时回调函数确实被调用了。那么只能说，其他地方调用了超时回调函数。查看代码，发现有两处调用超时回调函数，而且都是在串口中断中。那么很有可能是备用串口的接收中断接收到数据，调用了回调函数。于是在备用串口的中断函数中设置断点，调试发现，程序确实进入了备用串口的接收中断。

此时，使用示波器在出现异常数据的备用串口上进行测量，发现不定时的确实用低电平信号出现。程序运行异常的原因找到了。

首先修改程序，停止初始化出现异常数据的备用串口，删除备用串口接收中断中的执行代码，使其不操作和485相同的控制标志。

修改后，测试运行发现产品运行正常，没有再出现短时间内无线模块断开重连的现象。

后来在查找备用串口上异常数据的来源时，发现很奇怪。除去任何干扰源，在此串口的接收上还是会出现随机的低电平信号。在询问了硬件工程师后，建议测量下电源是否稳定。测量后，确认电源稳定没有异常。一段时间后，硬件工程师截图说这个信号是正常的。由于备用串口上连接了红外接收器，红外接收器一般会感应到一些红外信息发送给串口接收端。对比了红外接收器存在和不存在的采集器后，发现确实如果没有红外接收器备用串口接收上，电平正常。

 

关于这个问题，有几点反思：

1、对于程序中，对于没有用到的串口资源随意打开弃之不管，留下了一些未知的隐患。

2、备用串口和485串口的中断服务函数中使用同样的数据处理标识。原有代码将备用串口中断服务函数中的回调机制注释掉，来实现485串口的接收。这样的处理，很有可能是在程序设计的时候将原有备用串口的功能移植到485串口，但是却保留了原有函数中的几乎全部代码。并且在实际程序中，备用串口同样被初始化，备用串口的接收中断同样使能。而在修改的时候，将注释打开了。

3、在修改代码的过程中，没有将备用串口的初始化操作关闭。在打开备用串口中断服务函数中的注释时，没有进行详细的确认。确认打开注释后，对于现有的代码会造成什么样的影响。

4、红外接收器对于备用串口的影响，没有明确标示出来。再设计软件的时候没有明示，代码中未对备用串口的功用做描述。

5、详细的测试很重要。此次测试过程中虽然一共有20多个产品在运行，但是也只有两个产品出现异常。致使我们发现问题，如果只测试了少数的几个，可能这种现象就不会表现出来。如果到了客户那里才发现，就得紧急测试及到客户那里进行程序升级。将会是很大的时间及成本的开销。

 

总结：

程序中不必要的代码尽量删除，不必要的资源尽量关闭。

注释的打开与关闭慎之又慎。

全面的测试必须进行，细小的问题不能放过。