尧图网站建设 
简介面向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 用一张表看懂三种模式的核心差异模式CPU状态外设与RAM唤醒源唤醒后流程电流量级参考Sleep停止全部保持任意中断/事件从中断继续执行像打了盹mA级其实只是CPU歇了Stop停止主时钟停止RAM和寄存器内容保留可选RTC继续走RTC闹钟、外部中断、任何EXTI从中断服务程序返回主时钟要重新恢复uA级Standby停止RAM丢失相当于复位RTC闹钟、WKUP引脚、外部复位系统从头复位执行uA级甚至更低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_reasonRTC回调里置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我实测的量级如下配置组合实测电流参考Sleep模式几mA实际由外设时钟决定Stop模式所有GPIO配置为模拟输入5-10uAStop模式 LSE RTC继续运行10-15uAStop模式 外部中断唤醒内部上拉10-20uAStop模式 IWDG没有妥善处理复位周期内平均电流可能升到几十uA连接调试器时的Stop模式几百uA到几mA注意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定时唤醒分步确认每一层的功耗排查会轻松很多。本文还有配套的精品资源点击获取 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 用一张表看懂三种模式的核心差异模式CPU状态外设与RAM唤醒源唤醒后流程电流量级参考Sleep停止全部保持任意中断/事件从中断继续执行像打了盹mA级其实只是CPU歇了Stop停止主时钟停止RAM和寄存器内容保留可选RTC继续走RTC闹钟、外部中断、任何EXTI从中断服务程序返回主时钟要重新恢复uA级Standby停止RAM丢失相当于复位RTC闹钟、WKUP引脚、外部复位系统从头复位执行uA级甚至更低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_reasonRTC回调里置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我实测的量级如下配置组合实测电流参考Sleep模式几mA实际由外设时钟决定Stop模式所有GPIO配置为模拟输入5-10uAStop模式 LSE RTC继续运行10-15uAStop模式 外部中断唤醒内部上拉10-20uAStop模式 IWDG没有妥善处理复位周期内平均电流可能升到几十uA连接调试器时的Stop模式几百uA到几mA注意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定时唤醒分步确认每一层的功耗排查会轻松很多。本文还有配套的精品资源点击获取