一次“睡了但没完全醒”的排查某款电池供电的 GPS 追踪器，主控 STM32L4，需求是这样的：设备大部分时间处于 Stop 2 模式，每 30 分钟通过 RTC 唤醒一次，读取 GPS 定位，通过 NB-IoT 上报，然后继续休眠。同时，设备有一个按键，用户按下按键要能立即唤醒并触发一次上报。样机做出来，RTC 定时唤醒正常，但按键唤醒出了问题。按下按键后，设备偶尔会“醒来又睡回去”，或者唤醒后 GPS 不工作、NB-IoT 连不上。概率大概 10%，不高，但在量产测试中足以判不合格。排查发现，问题出在唤醒源的识别和状态恢复上：按键唤醒和 RTC 唤醒共用了唤醒处理逻辑，但两者的唤醒后处理流程完全不同。RTC 唤醒需要初始化 GPS 和 NB-IoT，按键唤醒只需要触发一次上报，不需要重新初始化 GPS。更严重的是，唤醒后没有检查所有唤醒标志。有时候按键和 RTC 同时触发（正好在 RTC 唤醒的瞬间按下了按键），处理逻辑只认了 RTC，按键事件被丢失。最隐蔽的问题是：从 Stop 模式唤醒后，部分外设的时钟没有恢复。GPS 的串口时钟在进入 Stop 前被关闭，唤醒后没有重新使能，导致 GPS 数据读不到。这个案例的核心问题是：唤醒源管理没有系统化。唤醒源识别、唤醒标志清除、唤醒后状态恢复，这三件事没有形成完整的工程方法。这篇文章要讲的，就是唤醒源管理的工程方法。一、唤醒源有哪些常见的唤醒源类型