知识点扫盲：由于串口发送中断导致的批量事故

大家好，很高兴和各位一起分享我的第45篇原创文章，喜欢和支持我的工程师，欢迎给我点赞、收藏、分享。

加微信[xyzn3333]与作者沟通交流，免费获取更多单片机与嵌入式的海量电子资料。

欢迎关注【玩转单片机与嵌入式】公众号，回复关键字获取更多免费资料。

回复【3D封装库】，常用元器件的3D封装库；

回复【电容】，获取电容、元器件选型相关的内容；

回复【阻抗匹配】，获取电磁兼容性、阻抗匹配相关的资料

回复【资料】，获取全部电子设计、单片机开发相关的资料

回复【终端电阻】，获取CAN终端电阻相关的资料

回复【单片机】，获取单片机全套视频教程和参考设计

回复【STM32】，获取STM32相关设计和视频教程

回复【PCB】，获取PCB设计相关的资料

回复【硬件知识】、【硬件设计】，获取硬件开发工程必备手册

回复【经典电路】，获取5000个经典电路

回复【论文】，获取毕业设计、电子竞赛、学术专业等相关论文资料

…………

欢迎关注【玩转单片机与嵌入式】公众号，本公众号会以连载的形式对电容进行深入讲解，欢迎持续关注。

0、前言

某天，正在公司专心上班，为了一行代码应该如何优化绞尽脑汁；突然接到售后服务同事的电话："告诉你一个不好的消息，xx客户处的设备，出现上电后慢速行驶灯会无规律闪烁的情况"。

由于从事的行业比较特殊，任何的异常都有可能导致涉及人命的安全事故；再加上“事出异常必有妖”，这种心态的作用。客户反馈的事情瞬间提升到最高优先级。

赶紧放下手头事情，整个人被“中断”出去处理紧急异常事故。

1、故障复现

按照现场的工作条件，在公司搭建测试环境后，发现异常果然存在。但是只在A设备搭配B设备通信时出现异常。

2、排查事故影响范围

由于闪烁的是慢速行驶灯，若正常在快速行驶状态中，突然出现慢速行驶，会由于突然的速度变化导致不可预估的风险；

在测试中发现，仅仅是指示灯闪烁了一下，但实际行走模式未发生改变。悬着的心突然有了一丝丝安慰。

3、排查原因及步骤

1、A设备灯的状态是由B设备的工作模式来决定，B设备将自身的工作模式和模式状态实时（每10ms）发送给A设备，A设备仅仅负责根据数据执行即可。

2、监听A设备和B设备通信的数据，发现B设备发送数据有丢失。按照理论来看，B设备发送数据有丢失，A设备应该不解析本报数据，本次10ms周期不进行指示灯状态切换即可，不应该出现闪烁。

3、模拟B设备故意每次均少发指示灯状态的数据；现象为A设备的指示灯完全不亮，符合逻辑；

4、模拟B设备仅少发1个周期的指示灯状态数据，其余周期正常；测试现象与故障现场的现象完全一致，B设备数据导致导致了本次事故。

5、基于以上的分析，将问题锁定在2个方向：

• B设备为什么会丢失数据？

  
  

• B设备丢失数据时，A指示灯为何会闪烁？

  
  

4、问题的根源定位

检查A设备的程序后，很快发现了问题原因：仅丢失一包数据时，由于后面的数据校验错误，解析数据时将CRC值当做正常数据进行了解析；

通过更新A设备的程序，故障不再复现。

检查B设备的程序查找数据丢失的根本原因。因为简单的知识点盲区，卡住了2天。最终查到的问题原因如下：

B设备发送使用了串口发送中断，更改前的流程：

更改后的流程：

5、知识点扫盲

STM32的串口发送中断是TC，即Transmission Complete。发送一个字节后才进入中断，这里称为“发送后中断”。和原来8051的TI方式一样，都是发送后才进中断，需要在发送函数中先发送一个字节触发中断。并不是开启发送中断后自动进入发送中断。

End