STM32 Stop模式低功耗与RTC/外部中断唤醒实战指南

简介：面向STM32F103低功耗应用开发，这份资料提供完整的Stop模式进入与RTC+中断唤醒工程方案。内容涵盖RTC时钟源配置、闹钟中断设置、EXTI外部事件唤醒，以及基于HAL库HAL_PWR_EnterSTOPMode的低功耗状态切换代码，可直接移植到实际项目中。工程基于Keil MDK搭建，除源码外还包含编译脚本、链接脚本和烧录配置文件，便于二次开发。资源共212个文件，以C源码、H头文件及编译生成的O目标文件、D依赖文件为主，压缩包大小5.25MB，目录结构清晰，适合嵌入式入门与进阶者对照学习。目前已有8254人浏览学习，配套讲解可帮助理解低功耗模式下时钟树变化与中断唤醒机制，是一份兼顾原理与实操的参考资料。 STOP模式调试那几天，我守着万用表和示波器来回折腾，最后发现问题居然出在一个毫不起眼的GPIO悬空引脚上。如果你也正准备用STM32做电池供电的设备，想用Stop模式降功耗，再用RTC闹钟或者外部中断把系统喊醒，那这篇笔记应该能帮你少走不少弯路。围绕STM32的Stop模式低功耗及唤醒，我把RTC和中断的完整配置链路、实测数据以及几个隐蔽的坑从头到尾梳理了一遍，适合正在做便携采集设备、传感器节点、表计类产品的朋友参考。

1. Stop模式不是“睡得越死越好”：三种低功耗模式的选择逻辑

STM32的低功耗模式不止一个，很多新手上来就盯着数据手册里的电流数字，觉得哪个电流低就选哪个，结果往往在唤醒之后的初始化上栽跟头。我先把Sleep、Stop、Standby这三个最常用的模式放在一起对比，再解释为什么大多数项目最终都落在Stop上。

1.1 用一张表看懂三种模式的核心差异

1.2 实际项目里为什么普遍选中Stop

我最早做的那台低功耗采集设备，甲方需求很简单：平时啥也别干，每隔10分钟醒来一次，读一下传感器，通过无线模块发出去，然后继续睡。看起来Standby的功耗最低，但它有个致命问题——RAM里的数据全没了，任何运行状态、校验值、标志位都得靠串行Flash或者备份寄存器重新恢复，代码等于每次唤醒都从上电开始跑一遍，复杂度成倍上升。

Sleep的问题则相反，唤醒虽然快，但所有外设的时钟还在跑，电流压在mA级别，对电池供电设备来说撑不了太久。Stop模式正好卡在中间：内核和外设主时钟都停掉，RAM和寄存器原封不动，RTC负责继续计时，一颗纽扣电池能撑很久。唤醒后只要把HSE和PLL重新拉起来，外设重新初始化一遍，就能接着干活，不需要像Standby那样推倒重来。所以只要不是极端追求功耗的产品，Stop都是综合性价比最高的选择。

2. 进入Stop模式之前：时钟、GPIO和看门狗，少一个都会翻车

Stop模式听起来简单，一行HAL_PWR_EnterSTOPMode()就进去了，但真正坑人的全在前面这堆准备配置上。我总结成三类：时钟源、引脚状态、看门狗，每个都有血泪教训。

2.1 RTC时钟源的选择：LSE还是LSI

如果你要用RTC在Stop模式下继续走时间，先得定好RTC的时钟源。STM32F103的RTC有两个可选时钟：LSE外部32.768kHz晶振和LSI内部40kHz低速振荡器。

LSE的优势是精度高，晶振本身是为时钟设计的，温度漂移小，做日历和时间记录更靠谱，但需要外部电路和起振时间。LSI省了一颗晶振，内部自带，上电就能用，但精度不行，拿来日常计秒可以，攒上几个月误差会明显变大。我做的设备需要记录精确时间戳，所以选了LSE。如果你只是周期性唤醒，对时间精度没要求，用LSI完全够。

还有一个容易忽略的点：F103的RTC和备份寄存器都挂在备份域上，操作RTC之前必须使能PWR和BKP时钟，并且调用PWR_BackupAccessCmd(ENABLE)打开备份域访问权限。不然你会发现RTC寄存器写不进去，闹钟设了等于白设。用HAL库时这部分通常是内部处理好的，但如果你翻到标准库代码或者看老教程，会遇到这个坑。

2.2 引脚漏电流：低功耗的大敌藏在最容易被忽略的地方

进入Stop模式时，所有GPIO引脚的状态必须是确定的。浮空输入的引脚会像天线一样吸收外部噪声，产生微安到几十微安的漏电流，这在别的场景下可以忽略，对于目标是uA级功耗的低功耗设计就是灾难。

我的做法是：把当前用不到的引脚全部配置为模拟输入，因为模拟输入模式下引脚内部不再连接上下拉，也不存在输入缓冲漏电，是STM32引脚功耗最低的状态。如果某个引脚接了外部上拉电阻，还得看这个电阻另一端是否挂在电源上，最好是引脚配置成输出低电平，让电阻上不产生额外压降。

另外，如果板子上的LED、分压电阻、LDO反馈网络没有处理干净，它们带来的电流可能比STM32本身大几十倍。那次我测到待机电流卡在200uA下不去，一层层排查，最后发现是某个接在VDDA上的分压电阻一直在耗电。低功耗从来不是只改代码就能搞定的事，必须从原理图开始就考虑。

2.3 开启的看门狗会让你永远睡不踏实

独立看门狗IWDG在Stop模式下依然会继续计数，因为它使用LSI作为时钟，并不依赖系统主时钟。如果你在程序里打开了IWDG，进入Stop模式前没有提前喂狗，进入低功耗后计数器照常递减，一旦溢出系统就直接复位，看起来就像低功耗模式没生效一样。

我当时排查这个问题时，示波器抓到复位引脚周期性拉低，才意识到是IWDG在捣鬼。处理办法通常是两种：要么在低功耗期间关闭看门狗，但这在F1上比较麻烦，因为IWDG一旦开启就关不掉；要么在设计之初就把低功耗时间控制在看门狗超时周期之内，或者干脆在低功耗场景下不使用IWDG。窗口看门狗WWDG也类似，别想当然觉得“睡觉了它们也休息”，它们比你还敬业。

3. RTC闹钟唤醒全链路：从时钟配置到中断回调

RTC唤醒是Stop模式里最常用的方案，因为它不需要外部信号，系统自己定时醒来。但STM32F103的RTC闹钟有个非常容易踩的坑，我放在前面先说。

3.1 闹钟的一次性陷阱：F1系列和F4系列不一样

STM32F1的RTC只有一个闹钟Alarm A，而且这个闹钟本质上是“匹配一次就触发”，触发之后并不会自动重新加载下一次闹钟时间。你必须在每次闹钟中断回调里，重新设置下一次的闹钟时间，才能实现周期唤醒。

F4/ L4系列的RTC多了一个专用的可自动重载的WakeUp定时器，配置起来简单得多。但F1没有这个外设，很多人拿F4的教程往F1上套，就会遇到“第一次能唤醒，之后就再也不醒了”的问题。我调试时第一次碰到也是愣了半天，后来看参考手册才发现Alarm是one-shot的。所以用F1做周期唤醒，代码框架必须包含“唤醒后重设闹钟”这一步。

3.2 中断链路：为什么RTC闹钟能唤醒Stop模式

在F103上，RTC闹钟触发后，硬件逻辑会产生一条中断请求，同时这条信号还会被连接到EXTI的第17条线。EXTI17在NVIC中被映射为RTC_Alarm_IRQn，而EXTI事件的特性是能够把处于Stop模式的芯片从睡眠中唤醒。所以你看到嵌套向量中断控制器里挂的是RTC闹钟中断，实际上唤醒能力来自EXTI这条线。

理解这一点很重要，因为如果NVIC里RTC闹钟中断没有使能，或者EXIT线没有正确配置，闹钟到了时间也不会把系统唤醒。使用HAL库时这个过程封得比较严实，但要知道背后发生了什么，排查问题时才有方向。

3.3 一个能用的周期唤醒代码框架

给出一个我实际调试通过的F103 + HAL库框架，目标：每隔10秒唤醒一次。

初始化RTC时，配置LSE作为RTC时钟源，并设置好日期时间。然后在主程序中调用设置闹钟的接口：

void Set_Alarm_Seconds(uint32_t seconds) { RTC_AlarmTypeDef sAlarm = {0}; RTC_TimeTypeDef sTime; RTC_DateTypeDef sDate; uint32_t now_sec; uint32_t alarm_sec; HAL_RTC_GetTime(&hrtc, &sTime, RTC_FORMAT_BIN); HAL_RTC_GetDate(&hrtc, &sDate, RTC_FORMAT_BIN); // 读日期会把当前时间锁存，顺序不能反 now_sec = (sTime.Hours * 3600) + (sTime.Minutes * 60) + sTime.Seconds; alarm_sec = now_sec + seconds; // 天数进位需要单独处理，但Seconds / Minutes / Hours 直接取模即可 sAlarm.AlarmTime.Hours = (alarm_sec / 3600) % 24; sAlarm.AlarmTime.Minutes = (alarm_sec % 3600) / 60; sAlarm.AlarmTime.Seconds = alarm_sec % 60; sAlarm.AlarmDateWeekDay = RTC_ALARMDateWeekDaySel_WeekDay; // 按日期匹配 sAlarm.Alarm = RTC_ALARM_A; if (HAL_RTC_SetAlarm_IT(&hrtc, &sAlarm, RTC_ALARM_A) != HAL_OK) { Error_Handler(); } }

注意在初始化阶段设置第一次闹钟时，调用了一次HAL_RTC_GetTime / GetDate，必须连续读两次，因为BKP域里时间寄存器在读取一次后会被锁定，第二次读取才拿到正确值，HAL库的GetDate内部会做解锁，所以顺序一定先GetTime再GetDate。

闹钟中断回调里，重新设置下一次闹钟，同时做业务工作：

void HAL_RTC_AlarmAEventCallback(RTC_HandleTypeDef *hrtc) { // 业务逻辑：比如采集传感器数据 Sensor_Collect(); // 重新设定下一次闹钟 Set_Alarm_Seconds(10); }

中断服务函数不要忘了在stm32f1xx_it.c里挂上：

void RTC_Alarm_IRQHandler(void) { HAL_RTC_AlarmIRQHandler(&hrtc); }

进入Stop模式前的最后一步是调用：

HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

这行代码执行后，系统时钟停摆，但RTC依旧跑，等闹钟到来，EXTI17把系统拽醒，代码回到HAL_PWR_EnterSTOPMode的下一句继续执行。

4. 外部中断唤醒：按键和传感器脉冲叫醒CPU的配置细节

RTC负责定时唤醒，外部中断负责“随机唤醒”。比如用户按一下按键、传感器送来一个脉冲，设备需要立刻从停摆状态被拉起来干活。这两个场景是外部中断唤醒最常见的应用。

4.1 引脚配置：下降沿还是上升沿，别凭感觉

配置外部中断唤醒，第一步是确定触发沿。大多数情况下按键按下接地，所以按键引脚平时通过上拉保持高电平，按下瞬间变低，适合用下降沿触发。

但这里有个低功耗设计的细节：加入外部上拉电阻时，上拉电阻本身会一直消耗电流。如果非要上拉，阻值选大一点，100k或470k，把漏电流压到最低；或者STM32内部上拉本来就够用的话，直接用内部上拉就行。我实测过，内部上拉在Stop模式下的额外电流在可接受范围内，但外部上拉选小了会增加几十uA，完全得不偿失。

还有一种场景是传感器输出脉冲唤醒。比如一个低功耗的霍尔传感器，平时输出低电平，检测到目标时输出一个高脉冲，那你就应该配置成上升沿触发。关键在于了解外部信号的默认电平和有效电平，选对边沿，不然中断永远不来。

4.2 EXTI中断到唤醒的完整代码

以PA0为例，配置按键唤醒：

GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_AFIO_CLK_ENABLE(); GPIO_InitStruct.Pin = GPIO_PIN_0; GPIO_InitStruct.Mode = GPIO_MODE_IT_FALLING; GPIO_InitStruct.Pull = GPIO_PULLUP; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); HAL_NVIC_SetPriority(EXTI0_IRQn, 0, 0); HAL_NVIC_EnableIRQ(EXTI0_IRQn);

中断服务函数：

void EXTI0_IRQHandler(void) { HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0); }

回调函数中置标志位：

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == GPIO_PIN_0) { wakeup_reason = WAKEUP_BY_KEY; } }

进入Stop模式前不需要额外操作，因为EXTI中断的唤醒能力默认就在。按键按下，下降沿触发EXTI，系统被唤醒，中断服务函数执行完，主程序继续跑。

4.3 多唤醒源共存时怎么判定是谁叫醒的

实际产品很少只有一种唤醒源，RTC定时唤醒加外部中断随时唤醒是标配。这时进入Stop模式前，需要把所有允许唤醒的中断都使能，然后在中断回调里记录唤醒原因，主程序醒来后根据原因执行不同分支。

我常用的做法是定义一个全局变量wakeup_reason，RTC回调里置WAKEUP_BY_RTC，外部中断回调里置WAKEUP_BY_KEY。在Stop模式恢复后的第一件事，就是读取这个变量，然后执行对应功能，等到低功耗前的收尾阶段再把它清零。这里要注意，中断回调在唤醒瞬间已经执行了，所以标志位在HAL_PWR_EnterSTOPMode返回后依然保留，不会丢失。

另一个容易踩的坑是：如果按键唤醒引脚在唤醒后仍然保持低电平，而你又没有在中断回调之后清除EXTI的挂起标志，系统可能马上再次进入中断，导致不断唤醒。HAL的HAL_GPIO_EXTI_IRQHandler内部会清理挂起位，但如果按键一直按着，每次唤醒后还会再触发一次。这种情况下要在判断外部中断线电平之后，决定是否进入Stop，或者用软件做一个几毫秒的去抖窗口。

5. 实测电流与唤醒时间：测量方法、量级和一个循环唤醒坑

代码写通不等于低功耗达标，数据才是唯一标准。我把实际的测量方法和量级数据整理了一下，顺便讲一个让我排查到深夜的循环唤醒坑。

5.1 正确的测电流姿势

测量低功耗电流，最直接的办法是把万用表串进电源回路里，用电流档测。但普通万用表电流档的内阻和分辨率有限，测微安级电流时表本身会引入压降，导致被测电路电压偏低，反而影响工作。如果条件有限，至少要选带uA档的数字万用表，串联时确保供电电压足够。

精度更高的做法是用电流探头加示波器，或者专用低功耗电流表，能看到完整的电流波形。普通场景下，万用表串VDD就能得到一个可靠量级，够日常判断问题。测量之前务必断开调试器，调试器不仅会额外耗电，还会悄悄破坏低功耗状态，我见过不少“进不了低功耗”的案例，拔掉ST-Link之后一切正常。

5.2 不同配置下的电流量级

以STM32F103为主控，供电电压3.3V，我实测的量级如下：

注意F103在数据手册上给的Stop模式典型值大概在uA级别，但我实测到的数值会略高一些，主要差异来自GPIO引脚状态、LSE振荡器、外围电路漏电。如果你的板子电流量级在几十uA以内，说明低功耗链路基本正常；如果直接测出mA级，大概率是某个外设没关或者引脚状态没处理干净，建议按上文2.2节逐个排查。

5.3 循环唤醒：我遇到过的最隐蔽功耗杀手

有一次我加了RTC闹钟唤醒功能之后，低功耗电流从10uA飙升到几十uA，中间还伴随着明显的周期性波动。一开始以为是RTC配置错了，翻来覆去check LSE起振、闹钟寄存器、中断标志，全都没问题。

后来用示波器并联采样电阻看电流波形，才发现系统每隔10秒醒来一次，但又没有完整跑完业务流程就重新睡了。问题出在闹钟时间设置上：我在初始化时直接取当前秒数加10作为闹钟，但日期进位没有处理，闹钟设置的时间比当前还早，导致RTC立刻匹配、立刻中断、立刻唤醒，主程序刚恢复又执行进入Stop的代码，形成了一个快的循环唤醒。

这类问题最可怕的不是逻辑复杂，而是它不会让系统崩溃，电流看起来也还在“低功耗”量级，实际上却比正常值高好几倍。排查手段就是抓电流波形，看唤醒频率，然后用串口打印唤醒原因，逐条确认是不是预期中的那种唤醒。把时间补偿逻辑改成正确的取模运算之后，电流立刻回到了正常范围。

6. 唤醒后的恢复流程：Stop和复位不是一回事，活着回来只是开始

从Stop模式醒来，系统并不是满血复活。主时钟停了、外设状态可能残留、中断标志可能还挂着，处理不当会出现各种“醒来后行为异常”的诡异问题。

6.1 先查唤醒标志，再决定走哪条初始化分支

唤醒后的第一件事，是明确这次是谁叫醒的。RTC回调、外部中断回调里都会置标志，主程序醒来后先读这个标志。如果是RTC唤醒，就执行周期任务；如果是外部中断唤醒，就执行按键应答或者传感器读取；如果标志都没置，那就要警惕是不是复位，需要重新走完整初始化流程。

如果不清标志就直接进入Stop，下一次醒来会误以为还是上一次的唤醒原因，业务逻辑就会跑偏。所以建议在每次低功耗的收尾阶段统一清零。

6.2 重新启动HSE/PLL，外设也逃不掉重新初始化

Stop模式会关闭HSE和PLL。唤醒后，如果你需要使用外部晶振或者让系统跑在72MHz高主频下，必须重新调用系统时钟初始化函数，比如HAL_RCC_ClockConfig或者标准库里的SystemInit相关流程。否则系统会停留在默认的HSI 8MHz甚至更低的频率，外设分频配置也会跟着错乱，串口波特率、定时器定时时间全都会跑偏。

外设同样需要重新初始化。进入Stop模式之前，我习惯先把不需要的外设全部DeInit，清掉DMA、定时器、串口的挂起中断；唤醒后再重新初始化必要外设。这样能避免外设残留状态导致的异常中断——比如UART接收中断在睡眠期间积累了一堆标志，一唤醒主程序还没来得及处理就进入中断风暴。

6.3 调试期可用的一个朴素好习惯

低功耗调试阶段，我喜欢在关键位置翻转一个GPIO，用来观察进入Stop、唤醒、业务完成这几个节点的时间点。用示波器或逻辑分析仪就能直观看到不依赖串口的状态变化，功耗分析和时序分析都很方便。

量产之前记得把这个调试GPIO去掉或者改回普通用途，不然你在低功耗测量时会发现电流平白多了一路翻转引脚的功耗——这个“调试接口没关”的问题，其实比想象中更常见。

根据我个人这几轮调试的经验，低功耗设计是个系统工程，别把精力全部放在代码上，PCB的原理图、外围电阻、晶振选择、调试器连接状态都会直接影响最终电流数据。先把硬件基础打好，再把软件流程理清，STOP模式其实没那么可怕。如果你也在做类似的低功耗唤醒项目，建议从最简单的Stop模式纯外部中断唤醒做起，电流正常再加RTC定时唤醒，分步确认每一层的功耗，排查会轻松很多。

本文还有配套的精品资源，点击获取