单片机程序死机问题分析

只看该作者 · 2022-10-27 11:16

（1）
单片机潜在的死机原因：
1 数组越界/溢出
现象：单片机程序在函数中运行时，总是在运行到函数末尾，要跳出函数时，程序跑飞。
原因：
数组越界（数组溢出），函数中定义的数组元素的个数小于程序中实际使用的数组元素的个数，例如在函数中定义了一个数组ucDataBuff[10]，这个数组只有10个元素，但是在函数中却有这样的语句ucDataBuff[10]=0x1a,这个语句是给数组的第11个元素赋值，：由于定义的数组只有10个元素，从而导致赋值语句中不知道把0x1a放到什么地方，从而导致程序跑飞。
解决方法：
如果在调试程序时，发现程序总是在函数执行完毕时跑飞，多数情况是发生了数组越界（数组溢出）的错误，仔细检查函数中调用的数组是否存在越界（溢出）的情况。

2 中断服务程序缺失
现象：程序运行过程中总是跑飞。
原因：程序中打开了某个中断，但是却没有相应的中断服务程序，从而导致在中断发生后，找不到中断服务程序入口，从而导致程序跑飞。
解决方法：检查程序中是否存在打开了某个中断，但是没有相对应的中断服务程序。

3 看门狗复位
现象：在执行一段较为耗费时间的程序时，程序跑飞，并且总是跳到复位位置处。
原因：程序中使用了看门狗，但是没有及时“喂狗”，从而导致看门狗复位，使程序直接跳到复位位置。
解决方法：根据程序运行时间，尤其是一定要计算清楚最耗时的那段程序的运行时间，然后准确设置看门狗的复位时长，定时“喂狗”，尤其是如果有死循环的情况，一定要在死循环中记得“喂狗”。

硬件层的应对策略：

软件层的应对策略：

（1）多任务环境中如何喂狗

假设系统中有4个任务，DefaultTask、Task01、Task02、Task03。我们先建立一个全局变量dog_flag用于存储各个任务的喂狗状态；在前3个任务的主循环中，把dog_flag对应的bit位置位，DefaultTask置位bit0、Task01置位bit1、Task02置位bit2；在最后的Task03任务中，循环检查是否所有在使用的bit位都被置位，如果都被置位，则说明其他所有的任务的主循环都在正常运行，那么可以喂狗；同时最后要将dog_flag清零，以用于下一次监测置位。

（后记：，这段代码原先有点问题，对于dog_flag这个变量的读写，在多任务环境下是有可能冲突的，所以在访问它时，要当作临界段处理）
（2）事件标志组应用于多任务喂狗
在大部分的RTOS中，有一种更优雅的实现方式，那就是利用事件标准组。

我们之前讲freeRTOS的时候，在事件标志组相关的章节提到过，在事件标准组的变量中，每个bit位表示了一个事件，正好相对于这里我们用于监测各个任务主循环是否执行到的bit位。同时，事件标志组可以通知其他任务，我们可以利用这个特性，在喂狗的任务中等待其他所有任务的发送的事件标志，如果全都等到了，就喂狗并清除事件。
以freeRTOS环境为例，示例如下：