STM32U375 Standby模式进不去？低功耗排查指南与解决步骤

把 “standby on stm32u375 not reaching low power state” 这个问题摆到桌面上，做过低功耗开发的人都知道这是什么滋味：代码确实调用了HAL_PWR_EnterSTANDBYMode()，理论上这颗芯片应该掉到几百纳安，结果电流表上还挂着好几毫安，甚至程序还在继续跑。STM32U375 是 U3 系列的成员，这颗料的核心卖点就是超低功耗，Standby 模式加 RTC 唤醒的标称电流通常在几百纳安以内，所以遇到这种现象，基本可以断定是“没进到状态”，而不是芯片本身就该这么耗电。

这篇文章把我排查这个问题的完整过程整理出来：怎么用状态寄存器和复位标志确认“到底进没进 Standby”，哪些因素最容易把系统钉在运行态，量电流用什么工具和步骤才靠谱，最后给出一段可以直接抄的可靠进 Standby 代码。适合所有在 U5/U3 以及类似超低功耗 MCU 上做电池供电产品的工程师参考，尤其是第一次接触 U3 系列低功耗特性的人。

1. 先搞清“进不去”的三种表现

很多人一上来就翻寄存器，其实第一步应该先搞清楚你的“进不去”到底是哪一种。我实际踩下来，Standby 进不去的表现可以分为三类，排查方向完全不同，搞混了会浪费大量时间。

1.1 表现一：程序根本没停在那

最直观的一种：调用HAL_PWR_EnterSTANDBYMode()之后，后面的代码继续执行，LED 还在闪，串口还能打印。很多人第一反应是“芯片从 Standby 唤醒了”，其实压根没进去。

原因是 Cortex-M33 执行 WFI 指令时，如果此时 NVIC 里有 pending 的中断，内核不会进入 deepsleep，而是直接把 WFI 当空指令跳过，继续往下跑。所以程序看起来像是“唤醒后执行”，实际上是从未睡过。

验证方法很简单：在HAL_PWR_EnterSTANDBYMode()后面放一个while(1)或者翻转一个 GPIO。如果执行到了，说明肯定没进 Standby。

1.2 表现二：程序停了，但电流是毫安级

症状是程序确实停在 WFI 位置，不再执行后面的代码，但电流还是几毫安，离标称的纳安级差了十万八千里。这种最难查，因为软件已经“卡死”了，没有任何反馈通道。

这种情况通常是电源控制单元根本没有完成模式切换，最常见原因是调试器把 DBGMCU 的低功耗调试位打开了，导致内核时钟在 Standby 下依然保持；也有可能是某个硬件模块在请求总线，或者进入了 Stop 而不是 Standby。这类问题需要结合状态寄存器来判断，下面会详细展开。

1.3 表现三：周期性复位，电流呈锯齿波

第三种是用示波器看电流时，能看到周期性的尖峰，好像是“睡一下—醒一下—复位—再睡”的循环。这种基本上就是有东西在反复触发复位或反复唤醒。

常见的两个元凶：一是 IWDG 独立看门狗在 Standby 下继续跑，超时后把芯片复位；二是 WKUP 引脚悬空或者 RTC 唤醒周期太短，刚睡下去就被拉起来。这种问题用电流波形一眼就能看出来，比拿万用表看平均值直观得多。

把三种表现整理成一张速查表，方便定位：

2. 核武器：用 SBF 标志和复位原因判断真相

在动手查电流之前，先解决一个根本问题：怎么证明“到底进没进过 Standby”。U3 系列和传统 STM32 一样，从 Standby 唤醒后整个核心域重新上电，程序从头开始执行，看起来和冷启动完全一样。但有一个标志可以区分——PWR_SR2 寄存器里的 SBF（Standby Flag）。

2.1 Standby 唤醒后芯片会复位，SBF 会保留

进入 Standby 时，除了备份域和唤醒电路，其他全部掉电。因此醒来后 CPU 执行的是复位向量，不会从 WFI 后面接着跑。这意味着你不能在 WFI 后面写“醒来后要做什么”的代码，所有唤醒后的动作都得放在 main 函数开头，通过判断复位原因来区分。

PWR_SR2 的 SBF 位就是这个用途：如果上电后 SBF 为 1，说明这是从 Standby 唤醒的；如果为 0，说明是冷启动。判断完要记得通过 PWR_SCR 的 CSBF 位把它清掉，否则下次判断会出错。

if (__HAL_PWR_GET_FLAG(PWR_FLAG_SB) != RESET) { /* 刚从 Standby 醒来 */ __HAL_PWR_CLEAR_FLAG(PWR_FLAG_SB); } else { /* 冷启动 */ }

这个判断是整个排查流程的基石，比拿电流表猜可靠得多。

2.2 用 RTC 唤醒做一个“自证”试验

基于上面的原理，我强烈建议先做一个自证试验：配置 RTC 唤醒定时器，每隔 1 秒唤醒一次，在上电处翻转 LED 并检查 SBF。这个试验能直接告诉你芯片到底有没有进过 Standby。

int main(void) { /* 系统时钟、GPIO、LED 初始化略 */ if (__HAL_PWR_GET_FLAG(PWR_FLAG_SB) != RESET) { /* 刚从 Standby 唤醒：翻转 LED，证明我进去过 */ __HAL_PWR_CLEAR_FLAG(PWR_FLAG_SB); HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); } else { /* 冷启动：配置 RTC 每秒唤醒一次 */ MX_RTC_Init(); HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 32767, RTC_WAKEUPCLOCK_CK_SPRE_16BITS); } HAL_Delay(50); /* 让 LED 状态可被肉眼看到 */ Enter_Standby(); /* 进入 Standby */ while (1); }

观察几分钟 LED 的行为，结果只有三种可能：

• LED 周期性闪烁 → 芯片一直在“进入 Standby—被 RTC 唤醒”的循环里，说明能进，但可能有别的唤醒源在捣乱，或者你误以为进不去其实进去了。
• LED 只闪一下再也没动静 → 芯片第一次冷启动后确实进入了 Standby 且没有被唤醒，此时如果电流还很大，问题出在电源/调试器层面。
• LED 完全不闪 → 从未进入 Standby，问题在 WFI 之前的环节，重点查 NVIC、DBGMCU。

这个试验做完，排查范围直接缩小一半。我在好几个项目里用这个方法，五分钟内就能把问题定性。

2.3 别忘了看唤醒标志 WUF

如果确认“能进但反复被唤醒”，下一步就是查是谁把它叫醒的。PWR_SR2 里除了 SBF，还有一组 WUF1~WUF6，对应不同的 WKUP 引脚，还有一个 WUFI 之类的中断唤醒标志。在唤醒后的复位处理代码里读一下这些位，就能知道具体的唤醒源：

uint32_t sr2 = PWR->SR2; if (sr2 & PWR_SR2_WUF1) { /* WKUP1 引脚唤醒过 */ } if (sr2 & PWR_SR2_WUF2) { /* WKUP2 引脚唤醒过 */ } if (sr2 & PWR_SR2_WUFI) { /* RTC 等内部唤醒源 */ }

清标志时同样走 PWR_SCR，把对应的 CWUF 位置 1 即可。注意：如果不清除旧的 WUF 标志，下一次进入 Standby 可能被“历史遗留”的唤醒标志直接拉起来，表现为“第一次能睡，第二次就立刻醒”。

3. 第一嫌疑：调试器在背后搞鬼

如果你是在开发板上调试时发现电流不对，第一个要怀疑的就是调试器。这不是玄学，是硬件逻辑决定的。

3.1 DBGMCU 低功耗位是怎么把系统钉住的

STM32 的 DBGMCU 模块里有一个控制寄存器 DBGMCU_CR，其中三个位分别控制 Sleep、Stop、Standby 模式下调试接口是否保持活跃：

• DBG_SLEEP：置 1 时，内核时钟在 Sleep 模式下继续跑。
• DBG_STOP：置 1 时，调试接口在 Stop 模式下保持打开。
• DBG_STANDBY：置 1 时，Standby 模式下调试时钟不关闭，稳压器不掉电。

问题就在这：当 DBG_STANDBY 为 1 时，芯片虽然执行了 WFI，但电源控制单元为了维持调试时钟，不会真正把核心域断电，电流自然停留在毫安级。很多集成开发环境在启动调试会话时，会自动把这些位配置为 1，保证调试过程中能随时停下来看寄存器。如果你烧完程序没有断开调试器就直接量电流，测试结果必然是假的。

更坑的是，这些位在调试会话结束后不一定复位。你拔掉 ST-LINK，它们可能还是 1，直到下次上电复位才会回到 0。

3.2 量电流前必做三件事

我的习惯是在量电流前固定执行这三步：

1. 拔掉调试器，或者至少断开 SWD 的两根数据线，让目标板完全独立供电。
2. 在代码初始化里显式清掉 DBGMCU_CR 的三个位，防止误配置：

/* 确保调试器不会阻止低功耗模式 */ DBGMCU->CR &= ~(DBGMCU_CR_DBG_SLEEP_Msk | DBGMCU_CR_DBG_STOP_Msk | DBGMCU_CR_DBG_STANDBY_Msk);