飞控算法从入门到精通 · 番外篇：飞控中的看门狗与系统监控从一次炸机说起去年夏天，我在调试一款自研四旋翼的定点悬停。飞控板是STM32F427，跑着FreeRTOS，传感器融合、姿态控制、位置控制三个任务按优先级排好。一切看起来稳如老狗——直到第三次试飞，飞机在离地两米处突然像被抽了魂，电机直接停转，自由落体砸在草坪上。事后拉日志，发现IMU数据在坠毁前200ms突然全部归零，紧接着是看门狗复位标志位被置位。但诡异的是，IMU的SPI通信在坠毁后测试完全正常。后来排查了三天，发现是姿态解算任务里一个浮点除法的分母在极端姿态下趋近于零，触发了硬件fault，而看门狗在fault处理完成之前就超时了。那次之后我彻底明白：看门狗不是保险丝，是最后一道防线的哨兵。你把它当保险丝用，它就给你表演“误杀”。看门狗在飞控里的真实角色飞控系统里，看门狗（Watchdog）的核心使命只有一个：在软件彻底死透或陷入死循环时，强制拉硬件复位。但飞控不是普通嵌入式设备——它不能容忍“复位重启”这种操作。飞机在天上，你复位一下，电机停转，那就是炸机。所以飞控里的看门狗，必须做到两件事：能检测到“软死”状态（任务卡死、中断风暴、堆栈溢出）在检测到“硬死”状态（硬件fault、内存访问违例）时，不要立即复位，先尝试自救很多初学者把看门狗当成“定时喂狗”的机械动作，这是大忌。飞控里喂狗
