一个让人抓狂的"随机死机"去年做一款便携式数据记录设备，主控用电池供电，大部分时间待在深度休眠模式，靠一颗三轴加速度计检测运动事件来唤醒。硬件同事把传感器中断引脚接到主控的外部中断口，软件配好之后，实验室桌面上测试一切正常——敲一下外壳，设备立刻醒来，串口打印数据，然后继续睡。问题出在老化测试阶段。二十台样机跑了两天，有三台彻底"失联"：电池电压正常，但设备再也不响应任何动作，必须拔电池重新上电才能恢复。更诡异的是，这种失联不是每次都发生，同一台机器有时候跑十几个小时没事，有时候半小时就挂。我们一开始怀疑是传感器本身死锁，换了料，问题依旧；怀疑是电源纹波导致主控复位不干净，加了滤波电容，还是照旧。真正定位到问题，是在一次偶然的调试中。我用调试器连着设备，发现"死机"的时候主控其实并没有死——它反复在进入休眠和退出休眠之间循环，只是每次醒来后立刻又睡回去，因为唤醒标志位没有被正确处理。换句话说，设备在"假醒"，用户看不到任何反应，但功耗却比正常休眠高了一个数量级。老化测试里那些"失联"的机器，电池其实是被这种异常循环慢慢耗光的。这个坑让我意识到，低功耗设计里唤醒源配置这件事，表面上只是填几个寄存器，实际上牵扯到中断标志清除时机、唤醒后的状态机跳转、以及多个唤醒源之间的优先级竞争。公开资料往往只告诉你"使能某个中断就能唤醒"，但真正让项目翻车的，是那些资料里不会写的细节。唤醒标志没清干净，等于没醒最常见的配置错误，是把唤醒中断使能了，但中断服务程序里只处理了业务逻辑，忘了清除唤醒标志。不同硬件平台对这件事的处理方式不一样，有的平台读一次状态寄存器就自动清标志，有的必须手动写1清除，还有的清除动作有
