关于通信程序的死机分析以及处理.pdfVIP

手心的嵌入式之家： 关于通信死机的分析以及解决方案 1 前 因： 前老化板程序经过测试发现，存在随机的死机现象。具体表现如下：多机通 信时，随着时间的进行，12 个模块存在随机的掉线过程。修改程序测试发现， 掉线以后的模块在掉线以后串口中断都不再进入。由于该现象是几个小时（一般 大于2 个小时）通信以后出现的随机现象，故使用仿真头等一般的手段难以找出 问题所在。 2 分 析： 鉴于使用仿真头等一般的手段难以找出问题点。通过咨询21IC 网友后，感 觉原通信程序架构是否存在先天性的bug 。原通信程序的架构特点如下： 发送缓冲区和接收缓冲区共用同一个缓冲区。接收到完整的一帧数据以后，关闭 接收中断使能，转而进入后台解析帧数据处理。如果该帧数据校验通过，同时是 发送给本机的命令，进入发送编码，然后开启发送中断发送数据。 结论1：存在频繁的中断开关动作。不合理，网友分析得到。 经过仔细的分析，如果系统处于单机通信模式下，该通信程序的架构不存在问题。 同时也有几个好处，由于是半双工的通信，在共用缓冲区的情况下，在LPC922 上RAM 资源匮乏的情况下（256B ）可以节省大量的RAM 空间。 但是，多机通信的时候，不免存在一些问题。具体分析如下： 可能的故障时序分析图 主机发送询问命令后，12 个从机同时收到了询问命令，由于12 个从机的程 序运行时间不尽相同，那么解析成功的时间也不尽相同。于是有一些从机先解析 1 手心的嵌入式之家： 完协议，有一些从机后解析完协议。如果先解析完协议的从机恰好地址符合，那 么该从机将进入应答模式，开始发送起始数据 0x3a 。后解析完的从机开启接收 中断时，则收不到0x3a 字节，于是，先完成的从机除了开始的几个字节数据没 有被后解析完的从机收到以外，后面发送的所有的数据都被后解析完的从机接收 到。由于结束符被收到，将导致新的一帧数据收到，产生新的解析。由于 LRC 校验本身并不是很完善，在某些情况下，LRC 校验对于多一两个字节的数据可 能校验不出来。于是，该模块将发生错误的解码成功。最终可能导致程序混乱。 从而发生掉线。 结论2 ：可能收到错误的数据来解析。不合理，自己分析得到。 3 解决方案调研： 经过咨询21IC 网友，得到了大概以下三种方案： 3.1 通用处理程序架构 采用《建立通用处理程序》（农民讲习所编写）一文中给出的方法，将整 个软件系统全部更改。经过通读和将文中的代码输入 Keil C 编译，受益还是比 较大的。但是，经过仔细分析，其给出的程序架构和目前自己使用的架构基本类 似，只是其实现方式以及编程风格有所不同，其实现多用指针以及自我分配内存 等，这个是比较灵活的地方。但是，其架构还是没有什么大的不同之处。同时， 其文中并没有针对串口通信给出具体的、有针对性的方案。无法应用到本次项目 改进当中。 3.2 采用循环队列 采用队列来做串口缓冲区。之前做通信代码的时候也使用过队列的方式。但 是由于队列的本身入列和出列的特点，编程中发现，对于这种RAM 资源很紧张 的情况下，用队列不太合适。因为采用了中断发送和中断接收，如果仅使用一个 队列来接收，将无法区分发送和接收的数据，换而言之，也就是需要一个接收缓 冲队列和一个发送缓冲队列。由于系统一帧数据最大接近 80BYTE 的数据量， 如果采用双缓冲队列的方式，仅用于通信就接近180 个BYTE（包括部分控制量）， 而系统其他部分还需要大概60BYTE 字节的RAM ，所以，系统的RAM 使用量 将达到240BYTE 左右。这样以来，系统的堆栈可以使用的资源就比较紧张。如 果AD 处理部分还要做滤波等处理的话，RAM 使用还要增加，故编写过程中发 现，使用队列来处理也不是很好。 当然，如果资源足够的话，采用队列来处理是最好的。之前也有过成功的应用经 验。