1. 低功耗调试概述：为什么需要系统化调试？
做低功耗产品，最怕什么？
不是功耗高，而是功耗忽高忽低。你测出来 10μA，客户拿到手变成 500μA。你以为是硬件问题，结果软件一更新又变了。我做了十几年嵌入式，踩过最大的坑就是——低功耗问题从来不是单一原因。
所以这一章，我们先聊聊：为什么低功耗调试必须系统化？常见的故障类型有哪些？调试的难点到底在哪？
1.1 为什么不能靠“试”来调功耗？
很多工程师的习惯是：功耗高了，就挨个关外设、降频率、改模式。试到功耗降下来为止。听起来挺直接，对吧？
但实际项目中，这种“试错法”有三大问题：
- 不可复现——你关掉某个外设功耗降了，但下次启动又回来了，你根本不知道是哪个条件触发的。
- 不可量化——你只知道“高了”或“低了”，但不知道每个模块到底吃了多少电流。
- 不可追溯——改完代码，过两周发现功耗又变了，你记不清当时改了啥。
核心观点：低功耗调试不是“修bug”，而是“做测量+做分析+做验证”的闭环。没有系统化方法，你永远在救火。
我个人习惯是：先搭测量环境，再写代码。哪怕只改一行，也要看电流波形。你想想看，如果连基线都没有，你怎么知道改对了？
1.2 常见低功耗故障类型
根据我这些年接触的项目，低功耗故障大致可以分成四类。我列了个表，方便你对照排查：
| 故障类型 | 典型表现 | 常见原因 |
|---|---|---|
| 静态漏电 | 休眠电流偏高，且稳定不变 | GPIO 未配置、上拉/下拉电阻冲突、LDO 使能未关 |
| 动态尖峰 | 电流波形上有周期性毛刺 | 定时器未关闭、RTC 唤醒周期过短、DMA 残留传输 |
| 模式切换异常 | 进入低功耗模式后电流不降 | 中断未屏蔽、外设忙状态未清除、时钟源未切换 |
| 唤醒后异常 | 唤醒后电流飙升且不回落 | 唤醒源配置错误、中断服务函数耗时过长、堆栈溢出 |
我的经验：静态漏电最好查，拿万用表一量就知道。动态尖峰最坑，必须用示波器或电流探头抓波形。我曾经有一个项目，休眠电流从 5μA 跳到 50μA，查了三天，最后发现是一个 GPIO 在休眠时被内部上拉了——嗯，就一个寄存器位的事。
1.3 低功耗调试的三大挑战
为什么低功耗调试比普通功能调试难？我总结了三座大山：
挑战一：测量精度与动态范围
STM32L4 在 STOP 模式下电流可以低到 1μA 以下，但运行时可能瞬间跳到 10mA。万用表测静态还行，测动态就抓瞎了。示波器配电流探头是标配，但探头噪声和带宽也会影响读数。
挑战二：调试器本身会“破坏”功耗
你插上 ST-LINK，芯片可能就退出了低功耗模式。我记得第一次用 STM32L4 时，插着调试器测 STOP 模式电流，怎么测都是 2mA。拔掉调试器，瞬间降到 3μA。从那以后，我养成了“拔线测量”的习惯。
挑战三：软件与硬件的耦合
低功耗问题往往是软硬件共同作用的结果。比如：
- 硬件上，某个电容漏电，软件怎么改都没用。
- 软件上，某个外设初始化顺序不对，硬件再干净也白搭。
所以系统化调试的第一步，就是先隔离硬件，再排查软件。
1.4 系统化调试的核心流程
说了这么多，到底怎么系统化？我画了一张流程图，把整个调试思路串起来：
这个流程看起来简单，但每一步都有坑。比如第一步“建立基线”，你至少需要知道：
- 芯片在 RUN、SLEEP、STOP、STANDBY 各模式下的理论电流是多少？
- 你的板子空载（不焊 MCU）时的漏电流是多少？
- 你的测量设备本身的误差范围是多少？
注意：不要跳过“空板测量”这一步。我曾经遇到一个项目，焊上 MCU 后 STOP 模式电流 20μA，怎么优化都降不下去。最后发现是 PCB 上某个去耦电容漏电——空板就有 15μA。你说这锅该谁背？
1.5 本课程能帮你解决什么？
这门课不是讲理论，而是讲实战方法。具体来说：
- 你会学会如何搭建一套可复现的低功耗测量环境。
- 你会掌握 STM32L4 各低功耗模式的寄存器级配置与调试技巧。
- 你会看到真实案例——从故障现象到根因定位的完整过程。
- 你会拿到一套可复用的调试检查清单，以后做新项目直接套用。
说白了，我希望你学完这门课后，遇到低功耗问题不再“靠猜”，而是能有条理地、一步步地把它拆解掉。