简介：面向STM32L431低功耗应用开发的工程资料，演示待机模式下的双唤醒策略——通过唤醒引脚和实时时钟闹钟实现外部信号与定时周期唤醒。待机模式是芯片最省电的工作状态，此时CPU、内存与外设全部停止，仅实时时钟与电压基准保持供电，非常适合电池供电设备。配套工程完整支持CubeMX和Keil开发流程，包含硬件初始化配置、外部中断唤醒代码、RTC闹钟时间重载与中断服务函数等，并给出了每分钟唤醒一次的定时配置思路。压缩包共188个文件，大小约1.09MB，涵盖HAL库源码、Keil工程文件、CubeMX初始化配置文件及编译输出文件，目录结构清晰，便于直接参考修改。已有6584人学习下载，适合需要快速掌握多路唤醒低功耗方案的嵌入式开发者；工程代码注释清晰，命名规范，可直接移植到同类低功耗项目中。 做电池供电产品的那段时间，我被低功耗折腾得够呛。项目用的主控是stm32L431，要求待机电流压到微安级别，同时还能被wakeup引脚和rtc闹钟随时唤醒。起初我也以为这玩意随便配一配就行，结果不是唤不醒，就是电流莫名其妙多出几百uA，翻了好几版代码才把整条链路跑通。这篇文章就围绕stm32L431待机模式这一条线，把两种唤醒方式的配置、代码和坑一次讲透，适合正在做电池供电传感器、门锁、遥控器、采集节点等低功耗设备的工程师。如果你现在只想把芯片丢进停机模式里凑合睡，这篇文章同样能帮你理清待机和停机到底差在哪。
1. 电池供电方案的功耗账本：为什么选待机而不是停机
1.1 一个真实项目里的功耗预算
先说一个我经常用的估算方法。假设设备每分钟被RTC闹钟唤醒一次，每次醒来跑10ms，平均工作电流按20mA算，剩下时间全部待在1.5uA左右的待机模式里。
- 一天被唤醒1440次，总工作时间就是 10ms * 1440 = 14.4 秒
- 工作耗电：20mA * 14.4s = 0.08 mAh
- 待机耗电：1.5uA * 24h = 0.036 mAh
- 一天总耗电约 0.116 mAh
如果电池是200mAh的扣式电池，理论续航就是 200 / 0.116 ≈ 1724 天，差不多4.7年。电池自放电、温度折损、无线发射瞬间大电流损耗再打五折，也有两年以上。这就是低功耗产品的核心逻辑：平均电流由待机电流主导，把待机电流压下去，整个方案的续航才谈得上有意义。
但很多人在第一步就卡住了。用默认配置跑一个最小系统，电流稳定在2mA左右，直接懵了。问题多半不是芯片差，而是选错了睡眠模式，或者根本没睡进去。
1.2 待机模式与其他低功耗模式的取舍
STM32L431这颗料提供了好几档睡眠模式，从浅到深分别是Sleep、Low-power sleep、Stop0/Stop1/Stop2、Standby、Shutdown。核心差异在于：内核和SRAM是否掉电、哪些唤醒源能用、唤醒后是“继续执行”还是“从头复位”。
| 模式 | 内核/SRAM | RTC | 唤醒方式 | 唤醒后行为 |
|---|---|---|---|---|
| Sleep | 内核停、SRAM保持 | 可跑 | 任意中断 | 从原处继续执行 |
| Stop2 | 内核/SRAM保持供电 | 可跑 | EXTI、RTC等 | 从原处继续执行 |
| Standby | 内核/SRAM断电 | 备份域供电 | WKUP引脚、RTC闹钟等 | 系统复位，从头跑 |
| Shutdown | 内核/SRAM断电 | 备份域供电 | WKUP引脚、NRST、TAMP | 系统复位，从头跑 |
实际做产品时，Stop2和Standby是大家最纠结的两个选择。Stop2的好处是SRAM数据还在，唤醒后能接着原来的上下文继续跑；缺点是电路上要处理的供电域多，调试复杂，而且电流通常比Standby略高一点。
Standby的好处是电流能做到极低，整个芯片除了备份域基本都断电了，代码流程也简单：醒来就是复位，从main开始走；坏处是SRAM内容全丢，任何跨待机的状态都必须提前存到RTC备份寄存器里。对于“定时采集上报”这类场景，Standby几乎是最合适的方案，因为醒来以后本来就要重新初始化外设、重新采集数据，保留SRAM没有太大意义。
1.3 为什么是L431
L431是STM32L4系列里非常适合做电池节点的一颗料，价格适中，外设够用，低功耗模式齐全。需要说明的是，L431不带原生USB控制器，想上USB得换L432系列。但对纯粹的传感器节点来说，没有USB反而省心，不用为用不上的外设付功耗。配合RTC闹钟和WKUP引脚这两种唤醒源，几乎能覆盖“定时上报+按键紧急唤醒”这类产品形态。
2. CubeMX配置阶段最容易埋雷的三个细节
2.1 时钟源：RTC一定要挂在LSE上
很多人习惯直接用CubeMX默认的RTC时钟源，结果实际测下来，待机电流是低了，但RTC时间不走，闹钟永远不触发。原因就是RTC时钟源默认挂在LSI上。
LSI是芯片内部低频振荡器，精度差，而且最重要的是：在待机模式下LSI默认是停的。你看着代码里HAL_RTC_SetAlarm_IT执行成功了，但进待机后RTC计数器根本不跑，闹钟比较自然永远不会命中。
正确的做法是在CubeMX里把RTC的Clock Source明确选为LSE。LSE是外部32.768kHz晶振，由备份域供电。待机模式下整个芯片主电源都断了，备份域依然由VDD或VBAT供电，LSE继续振荡，RTC日历才能继续走下去。
操作路径大概是：Pinout & Configuration -> RTC -> Activate Clock Source -> Clock Source选LSE。同时要保证RCC -> LSE配置为Crystal/Ceramic Resonator，如果你的板子没有焊32.768kHz晶振，那这个方案就不成立，需要先用WKUP引脚唤醒或者改硬件。
2.2 闹钟配置：不要在CubeMX里写死
CubeMX的RTC配置页面里有一个Alarm A的选项，可以勾选并设置一个固定闹钟时间。很多新手会顺手勾上，觉得“生成代码里就有闹钟了，多省事”。
这个做法在待机唤醒场景里非常坑。CubeMX生成的闹钟时间是一个写死的常量，比如09:30:00，它只会在每天或者某个固定日期触发一次。你没法在CubeMX里表达“从现在开始每隔60秒唤醒”这种动态逻辑，而且如果闹钟时间设置的是过去的时间，配合掩码不对，可能永远不触发或醒来后不再触发。
我的建议是：CubeMX里只开启RTC和Calendar，不勾AlarmA。闹钟的触发时间完全放在应用层代码里动态计算、动态设置。虽然多写几行代码，但逻辑清楚得多，尤其是做周期唤醒时，每次醒来都要重新设置下一次闹钟。
2.3 唤醒引脚不是普通EXTI
WKUP引脚是芯片PWR模块专门为低功耗唤醒设计的引脚，在STM32L431上，PA0映射为WKUP1，PC13映射为WKUP2。它和普通EXTI引脚有本质区别：
- 普通EXTI靠NVIC和时钟域工作，待机模式下内核和大部分外设时钟都断了，EXTI根本收不到信号。
- WKUP引脚检测逻辑在PWR模块内部，由备份域或独立逻辑供电，芯片主电源断了它依然能工作。
所以不建议把PA0在CubeMX里配成GPIO_EXTI0，然后指望外部中断能把芯片从待机里拉起来。正确做法是直接调用HAL库函数使能WKUP唤醒能力：
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1, PWR_WAKEUP_RISING);这里还有一个和F1系列不一样的坑。F1系列的HAL_PWR_EnableWakeUpPin只有一个引脚参数，没有边沿参数；L4系列多了第二个参数，用来选择上升沿还是下降沿唤醒。网上搜到的大部分F1代码在这里会编译报错，或者行为和你预期的完全不一样。
如果你的板子上有按键，最常见的接法是按键按下拉到高，那就选PWR_WAKEUP_RISING；按下拉到低，就选PWR_WAKEUP_FALLING。Nucleo-L431板子上的蓝色用户按键在PC13上，可以直接用WKUP2。
3. 代码层落地：动态闹钟、WKUP使能、待机进入与唤醒后处理
3.1 进待机前的固定流程
先明确一个前提：待机模式唤醒后的行为和复位一样，程序从main函数的第一行重新执行。所以代码里必须做两件事：判断是不是待机唤醒；判断唤醒源是谁。
每次进待机前，固定流程应该是四步：
- 清掉可能残留的RTC闹钟标志
- 设置下一次闹钟时间
- 使能WKUP引脚唤醒
- 调用HAL_PWR_EnterSTANDBYMode()
我把这四步封装成一个函数：
static void EnterStandby(uint32_t interval_sec) { // 1. 清掉可能残留的闹钟标志，否则刚睡下又会被拉起来 __HAL_RTC_ALARM_CLEAR_FLAG(&hrtc, RTC_FLAG_ALRAF); // 2. 设置下一次闹钟时间 SetRtcAlarm(interval_sec); // 3. 使能WKUP1引脚上升沿唤醒，PA0 HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1, PWR_WAKEUP_RISING); // 4. 正式进入待机模式，执行到这里后代码就“断电”了 HAL_PWR_EnterSTANDBYMode(); }3.2 动态设置下一次闹钟
RTC闹钟是一次性的，触发过就停了，必须每次唤醒后重新写新的闹钟时间。下面这段代码基于当前RTC时间加上一个偏移量，计算出下一次闹钟的时分秒，然后写入闹钟寄存器。
static void SetRtcAlarm(uint32_t seconds) { RTC_TimeTypeDef sTime = {0}; RTC_DateTypeDef sDate = {0}; RTC_AlarmTypeDef sAlarm = {0}; // 读时间前必须先读RTC_Time，再读RTC_Date，BKP寄存器是锁存的 HAL_RTC_GetTime(&hrtc, &sTime, RTC_FORMAT_BIN); HAL_RTC_GetDate(&hrtc, &sDate, RTC_FORMAT_BIN); uint32_t total = sTime.Hours * 3600u + sTime.Minutes * 60u + sTime.Seconds; total = (total + seconds) % 86400u; sAlarm.Alarm = RTC_ALARM_A; sAlarm.AlarmTime.Hours = total / 3600u; sAlarm.AlarmTime.Minutes = (total % 3600u) / 60u; sAlarm.AlarmTime.Seconds = total % 60u; // 关键掩码：只比较时分秒，日期和星期不参与匹配 sAlarm.AlarmMask = RTC_ALARMMASK_DATE_WEEKDAY; sAlarm.AlarmSubSecondMask = RTC_ALARMSUBSECONDMASK_ALL; sAlarm.AlarmDateWeekDaySel = RTC_ALARMDATEWEEKDAYSEL_DATE; sAlarm.AlarmDateWeekDay = 1; if (HAL_RTC_SetAlarm_IT(&hrtc, &sAlarm, RTC_FORMAT_BIN) != HAL_OK) { Error_Handler(); } }这里有个特别容易被忽视的问题：AlarmMask。如果这个掩码配的是RTC_ALARMMASK_NONE，意思是时间、日期、星期全都参与匹配。你只设置了时分秒，日期星期还是初始值，闹钟这辈子都可能不触发。我刚开始踩的就是这个坑，一晚上没唤醒，第二天查寄存器才发现是掩码问题。设置为RTC_ALARMMASK_DATE_WEEKDAY之后，日期和星期的比较被跳过，只认时分秒，闹钟才正常。
3.3 唤醒后如何判断是谁叫醒的
待机唤醒后，第一件事是看PWR_CSR寄存器里的SB标志（Standby Flag）。如果这个标志是1，说明这次启动不是冷上电，而是从待机模式被拉起来的。
判断完后要手动清除标志，否则下一次冷上电可能误判。
区分两个唤醒源，用RTC的ALRAF标志最直接。RTC闹钟触发后，硬件会把这个位置1。如果唤醒时ALRAF为1，就是RTC闹钟唤醒；否则就是WKUP引脚唤醒。
main函数骨架大概是这个样子：
int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_RTC_Init(); if (__HAL_PWR_GET_FLAG(PWR_FLAG_SB) != RESET) { // 这是待机唤醒，不是冷上电 __HAL_PWR_CLEAR_FLAG(PWR_FLAG_SB); if (__HAL_RTC_ALARM_GET_FLAG(&hrtc, RTC_FLAG_ALRAF) != RESET) { __HAL_RTC_ALARM_CLEAR_FLAG(&hrtc, RTC_FLAG_ALRAF); DoPeriodicTask(); // 定时唤醒：采集、上报、记录 } else { DoUrgentTask(); // 按键唤醒：紧急处理 } } EnterStandby(60u); while (1) { // 正常情况下执行不到这里 } }需要留意的是，待机唤醒后所有RAM变量都会被重新初始化，因为SRAM已经断电丢数据了。如果你需要跨待机保存“当前处于第几个采集周期”这类状态，要存到RTC备份寄存器里，方法是HAL_RTCEx_BKUPWrite和HAL_RTCEx_BKUPRead，而不是存普通全局变量。
另外，唤醒后系统时钟默认回到MSI，CubeMX生成的SystemClock_Config会重新把HSE配置好。如果你在SystemClock_Config之前就想操作依赖高速时钟的外设，比如串口打印，大概率会出乱码或数据错误。日志打印应该放在SystemClock_Config之后。
3.4 正常运行时RTC闹钟中断的回调
还有一点，如果你在正常运行状态下也给RTC闹钟开了中断，那么闹钟触发后会通过NVIC进入HAL_RTC_AlarmAEventCallback回调。这个回调不负责待机唤醒，只处理正常运行模式下的闹钟事件。回调里建议把ALRAF清掉，免得影响下一次判断。
void HAL_RTC_AlarmAEventCallback(RTC_HandleTypeDef *hrtc) { __HAL_RTC_ALARM_CLEAR_FLAG(hrtc, RTC_FLAG_ALRAF); }4. 实测电流数据与功耗偏高的排查
4.1 实测电流对比
我在自己的L431最小系统板上用万用表串联电源实测过几组数据，3.3V供电，断开一切调试器，板子没有额外LED和传感器，结果如下：
| 配置状态 | 实测电流 |
|---|---|
| 烧录后默认运行，MSI 4MHz | 2.1 mA |
| 进Stop2，RTC开启（LSE） | 1.8 uA |
| 进Standby，RTC闹钟+WKUP引脚都使能 | 1.5 uA |
| 进Standby，RTC不开启 | 0.5 uA |
如果RTC开启后电流依然有几十甚至几百微安，不用怀疑芯片规格书，先怀疑你的硬件连接和软件配置。
4.2 三种测量方式与常见误区
测待机电流时，最大的误区是带着调试器测。ST-Link上电后会给目标板的3.3V供电，同时VCP串口芯片也在跑，这部分的电流全部会算到你的“待机电流”里。实测中我遇到过带着ST-Link测出来2mA，拔掉ST-Link后立刻掉到1.5uA的情况，差距上千倍。测量低功耗设备，务必拔掉所有调试器和串口线，只保留供电。
测量仪器的选择也需要注意。普通万用表的uA档串进电源回路后，内阻一般在几十到几百欧姆，三个3V系统可能压降太大导致芯片无法正常启动或者唤醒后瞬间大电流把电压拉垮。如果你的设备启动瞬间电流很大，建议用示波器电流探头，或者用支持uA级别精度的直流电源分析仪来测。最简单的临时手段是用万用表mA档测工作电流，uA档测睡眠电流，分两轮完成。
4.3 电流死不下来的原因排查
我总结过几个排查顺序，从最高概率到最低概率依次是：
- 调试器或USB转串口模块还在供电
- 板上有外部上拉/下拉电阻、LED限流电阻
- GPIO处于悬空状态，电平不定导致IO漏电
- 外部传感器、LDO静态功耗太大
- 代码配置的模式其实是Shutdown而不是Standby
曾经遇到一个案例，待机电流怎么压都是300多uA。查到最后发现是板上的AMS1117稳压器本身静态电流就有5mA级别，这种LDO根本不适合做低功耗产品，换一个静态电流1uA以下的LDO，问题立刻解决。很多时候MCU已经睡得很深了，外设和电源芯片才是真正吃掉电流的元凶。
5. 待机唤醒后最常见的三个“假死”现场
5.1 现场一：RTC闹钟根本唤不醒
表现是芯片睡下去之后，等多久都不醒，只有按复位键才有反应。
排查思路按三步走：先看是不是进了Shutdown模式。L431的HAL库里，HAL_PWR_EnterSHUTDOWNMode和HAL_PWR_EnterSTANDBYMode长得很像，差一个寄存器的位，但Shutdown模式下RTC闹钟是不能唤醒的，只有WKUP引脚、NRST、TAMP入侵检测能唤醒。如果代码里不小心调成了SHUTDOWN，用RTC闹钟设计唤醒方案就会完全失灵。
再看RTC时钟源是不是LSE。如果留在LSI上，待机后RTC不走，闹钟永不命中。
最后用WKUP引脚测试一下能不能唤醒。如果WKUP能醒，RTC不能醒，基本可以锁定是RTC配置问题；如果WKUP也不能醒，问题可能出在芯片根本没进Standby，或者在唤醒引脚配置上。
5.2 现场二：第一次醒了，第二次再也没醒
这种情况最常见的原因是RTC闹钟没有重新设置。闹钟本质是一次性的，触发后硬件不会自动加载下一次闹钟值。你必须每次唤醒后、再次进待机前，重新调用HAL_RTC_SetAlarm_IT设置新的时间。
另外，如果第一次闹钟触发后ALRAF标志没有被清掉，下一次设置闹钟时可能因为标志残留导致行为异常。所以进待机前的步骤顺序很重要：先清ALRAF，再设置新闹钟，再进待机。我在代码里把这两步分开写，就是不想让顺序出错。
5.3 现场三：唤醒后程序“没反应”
还有一种情况是，电流消耗正常，芯片也确实被唤醒了，但外设看起来没工作，串口也没有打印。
这里要理解待机唤醒的本质：它不是中断返回，而是复位。程序从main重新执行，所有全局变量都是新值。如果你在代码里用了一个全局变量记录“第一次初始化是否完成”，待机唤醒后这个变量会被清零，逻辑会重新走一遍初始化流程，但有些外设的初始化时序会有问题。
正确做法是利用SB标志把“冷上电”和“待机唤醒”两条路径分开，把跨待机状态放到RTC备份寄存器里。同时，如果串口打印依赖HSE，一定要等SystemClock_Config执行完再打印，否则时钟还没切好，波特率是错的，打印出来就是乱码。
5.4 最后的一条建议
如果你也准备用L431做待机唤醒，我强烈建议先搭一个最小验证工程，把两个唤醒源单独测通以后再合并。先只开WKUP引脚，按一下按键看能不能唤醒；再只开RTC闹钟，看能不能周期性唤醒。两个都通了，再把业务逻辑加进去。我那次前前后后折腾了一天，最后发现代码逻辑本身没问题，就是ST-Link没断开，把待机电流拉高了上百倍。有些教训，确实要拿电流表才能教明白。
本文还有配套的精品资源，点击获取
