简介：STM32F429 FreeRTOS实战资源，面向嵌入式开发者，重点演示如何在STM32F42X系列上启用Tickless低功耗模式，通过RTC唤醒、任务超时管理、挂起恢复与中断适配等手段降低系统功耗，适合电池供电设备及低功耗物联终端项目参考。压缩包共234个文件，以c源码与h头文件为主，另有汇编启动文件、Keil工程配置、hex固件及readme说明，项目结构完整，可直接编译运行，便于在开发板上验证FreeRTOS的调度与休眠机制。已有254人学习/浏览，资源可在CSDN获取。通过该实例可快速掌握低功耗Tickless模式的移植步骤、时钟与中断配置思路，以及任务休眠与唤醒的实现细节，为后续嵌入式低功耗设计打下基础。
1. 不是加 WFI 就叫低功耗：Tickless 模式解决的是“被心跳反复叫醒”
把 STM32F429 FreeRTOS 工程改成低功耗，最常见的失败不是不会配置，而是把问题想简单了：在空闲任务里加一句 WFI，或者直接调HAL_PWR_EnterSTOPMode，电流却纹丝不动。原因在 SysTick 的 1ms 中断会把 CPU 从任何低功耗状态里拽回来，真正睡下去的时间远小于进进出出的开销。Tickless 模式要做的是先让 FreeRTOS 算出接下来至少有多个 tick 的空闲时间，把 SysTick 的下一次中断改到任务真正该醒来的时刻，再让 CPU 睡过去。这篇文章从 CubeMX 配置、SysTick 版 Tickless、Stop 模式边界到测量验证，按 STM32F42X 系列可复现的顺序写，F427、F429 的寄存器差异只有主频和外部晶振，剩下的逻辑通用。
2. CubeMX 和 FreeRTOSConfig：先让 HAL 与 FreeRTOS 不抢 SysTick，再开 Tickless
2.1 把 HAL 时基从 SysTick 挪到 TIM6
CubeMX 默认给 HAL 用的时基是 SysTick，FreeRTOS 默认的 tick 中断也是 SysTick。两个模块共用同一个中断，会在 Tickless 场景里互相拆台：Tickless 会频繁改写SysTick->LOAD和SysTick->VAL，HAL 再拿 SysTick 做毫秒计数，两边对不上，HAL_Delay和xTaskGetTickCount总有一个变慢。
常见做法是在 CubeMX 的 SYS 配置里把 Timebase Source 改成 TIM6。这样 FreeRTOS 独占 SysTick，HAL 的毫秒计数由 TIM6 中断驱动。生成代码后，中断入口应该是下面这种分家结构：
/* SysTick_Handler 里只放 FreeRTOS 的 tick 处理 */ void SysTick_Handler(void) { /* 如果使用 CubeMX 生成的 FreeRTOS 中间层，这里一般调用 xPortSysTickHandler() 或者 osSystickHandler() */ } /* TIM6 中断里只放 HAL 的毫秒计数 */ void TIM6_DAC_IRQHandler(void) { HAL_IncTick(); }不要自己额外在SysTick_Handler里调用HAL_IncTick()，否则 Tickless 睡完后时间会多跳一段。判别标准很简单：把串口的时间戳打开，跑一个vTaskDelay(pdMS_TO_TICKS(1000))，如果 1 秒任务周期在长时间 Tickless 后仍然稳定，说明时基没有打架。
2.2 FreeRTOSConfig.h 里必须出现的四个参数
CubeMX 生成 FreeRTOS 工程时，FreeRTOSConfig.h里的参数会被固定区域包裹。手写配置最好放在USER CODE BEGIN FreeRTOSConfig和USER CODE END之间，避免下次重新生成时被覆盖。
需要重点检查的参数如下：
| 宏 | 建议值 | 作用 |
|---|---|---|
configUSE_TICKLESS_IDLE | 1 | 打开 Tickless，让空闲任务进入内核级低功耗流程 |
configEXPECTED_IDLE_TIME_BEFORE_SLEEP | 2 | 连续空闲超过 2 个 tick 才允许进低功耗，太短会频繁进出 |
configUSE_IDLE_HOOK | 1 | 空闲钩子，用来放调试 GPIO 或统计代码 |
configUSE_TICK_HOOK | 0 | 关掉 tick 钩子，减少不必要的周期性唤醒 |
configTICK_RATE_HZ | 1000 | 系统 tick 频率，下面的换算都以这个 1ms 为准 |
在FreeRTOSConfig.h末尾加一个编译期检查，比运行时用串口打印更早发现问题：
#if ( configUSE_TICKLESS_IDLE != 1 ) #error "configUSE_TICKLESS_IDLE 没有生效，回到 CubeMX 重新确认" #endifconfigCPU_CLOCK_HZ也要一并核对。它决定 SysTick 的重装载值，建议不要写死数字，直接使用SystemCoreClock：
#define configCPU_CLOCK_HZ ( SystemCoreClock )F429 如果跑 180MHz，SystemCoreClock是 180000000；F427 如果跑 168MHz，它是 168000000。写死 168M 再超频到 180M，低功耗醒来后的 tick 补偿会整体偏快。
3. 跑通 SysTick 版 Tickless：port.c 里的三步操作和 PRE/POST_SLEEP 挂接
3.1 官方 port.c 已经实现 vPortSuppressTicksAndSleep，别急着自己写
FreeRTOS 的 ARM_CM4F 移植层里自带了vPortSuppressTicksAndSleep()实现，主流程被我压缩成下面这段。你在应用层不需要再写一个同名函数，除非后面要做 Stop 模式。
static void vPortSuppressTicksAndSleep( TickType_t xExpectedIdleTime ) { const uint32_t ulCyclesPerTick = configCPU_CLOCK_HZ / configTICK_RATE_HZ; const uint32_t ulSysTickCtrl = SysTick->CTRL; const uint32_t ulOldLoad = SysTick->LOAD; uint32_t ulCompleteTickPeriods; /* 关中断，避免刚算完空闲时间就被 tick 打断 */ portDISABLE_INTERRUPTS(); if( eTaskConfirmSleepModeStatus() == eAbortSleep ) { portENABLE_INTERRUPTS(); return; } /* 把 SysTick 下一次中断改到 xExpectedIdleTime 之后 */ SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk; SysTick->LOAD = ( xExpectedIdleTime * ulCyclesPerTick ) - 1UL; SysTick->VAL = 0UL; SysTick->CTRL = ulSysTickCtrl; /* 进 Sleep 前和醒来后各留一个钩子位置 */ configPRE_SLEEP_PROCESSING( xExpectedIdleTime ); __DSB(); __WFI(); __ISB(); configPOST_SLEEP_PROCESSING( xExpectedIdleTime ); /* 停掉 SysTick，读剩余计数值，算实际睡了几个整 tick */ SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk; ulCompleteTickPeriods = xExpectedIdleTime - ( SysTick->VAL / ulCyclesPerTick ); if( ( SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk ) != 0UL ) { ulCompleteTickPeriods++; } /* 恢复 1ms tick，再把漏掉的 tick 补进系统时钟 */ SysTick->LOAD = ulOldLoad; SysTick->VAL = 0UL; SysTick->CTRL = ulSysTickCtrl; vTaskStepTick( ulCompleteTickPeriods ); portENABLE_INTERRUPTS(); }代码里最关键的参数是ulCyclesPerTick。F429 在 180MHz 主频、1ms tick 下，这个值是 180000，也就是 SysTick 每数 180000 个时钟周期产生一次 tick。SysTick->LOAD是 24 位寄存器，最大 0xFFFFFF，所以单段 Sleep 最长大约是 93ms；长延时任务会分成多段睡，这是正常行为，不是 bug。
3.2 用 configPRE_SLEEP_PROCESSING 挂一个 GPIO 测量点
很多移植教程只改configUSE_TICKLESS_IDLE，却不把configPRE_SLEEP_PROCESSING和configPOST_SLEEP_PROCESSING用起来，结果根本没确认 CPU 是否真的睡下去了。这两个宏是调试 Tickless 最直接的抓手。
在FreeRTOSConfig.h里加：
#define configPRE_SLEEP_PROCESSING( x ) \ do { \ GPIOE->BSRR = GPIO_PIN_1; \ __DSB(); \ } while( 0 ) #define configPOST_SLEEP_PROCESSING( x ) \ do { \ GPIOE->BSRR = (uint32_t) GPIO_PIN_1 << 16U; \ } while( 0 )GPIOE Pin 1 拉高表示即将进入低功耗，拉低表示已经醒来。用逻辑分析仪抓这个引脚，高电平宽度就是实际睡眠时间。注意__DSB()是必要的，保证 BSRR 的写操作在 WFI 之前真正到达外设总线，否则 GPIO 可能还没来得及翻转就睡了。
3.3 最小验证任务只需要一个 vTaskDelayUntil
要验证 Tickless，不需要复杂业务逻辑，一个周期任务就够：
void vTaskToggleLed( void *pvParameters ) { TickType_t xLastWakeTime = xTaskGetTickCount(); for( ;; ) { HAL_GPIO_TogglePin( LED_GPIO_Port, LED_Pin ); vTaskDelayUntil( &xLastWakeTime, pdMS_TO_TICKS( 500 ) ); } }vTaskDelayUntil是绝对延时，不会因为中途被高优先级任务打断而累积漂移。任务每 500ms 醒来一次，其余时间都留在 Idle 任务里，Tickless 才有机会发挥。如果这里用HAL_Delay，由于 HAL 时基已经挪到 TIM6，延时本身没问题，但它不会主动让出 CPU，Tickless 的验证效果会变差。
4. 电流不降、醒来时间漂移：Tickless 实测和 4 个排错点
4.1 先建立基线再调参：用万用表串联测整板电流
调试低功耗最忌讳直接看整板电流绝对值。同一块 STM32F429 开发板，板载 LED、LDO、USB 转串口芯片都能贡献几十 mA，关掉这些再测。建议先记录三组数据：
| 场景 | 现象 | 优先排查方向 |
|---|---|---|
| 未开 Tickless | 电流只有微小波动 | 先确认外设和调试器已经断开 |
| 开了 Tickless | GPIO 波形从来没拉高 | configUSE_TICKLESS_IDLE被 CubeMX 覆盖 |
| 醒来后时间漂移 | 串口时间戳每隔几分钟慢几秒 | SysTick 恢复顺序错误，或vTaskStepTick没被调用 |
电流不降时，先看 GPIO 测量点有没有高电平脉冲。如果脉冲没有，说明问题根本不在低功耗本身，而是宏没生效；如果脉冲宽度只有几十微秒，说明空闲时间太短，把configEXPECTED_IDLE_TIME_BEFORE_SLEEP调大。
4.2 检查 SysTick 中断优先级是否被高优先级中断反复打断
FreeRTOS 的portDISABLE_INTERRUPTS()对 Cortex-M4 设置的是 BASEPRI，不是完全关中断。SysTick 的优先级必须低于或等于configMAX_SYSCALL_INTERRUPT_PRIORITY，否则关不掉，WFI 一执行就被 tick 叫醒。
检查 CubeMX 生成的HAL_Init()：
HAL_NVIC_SetPriority( SysTick_IRQn, 15, 0 );数值 15 在 Cortex-M4 里是最低优先级，这样 BASEPRI 能把它屏蔽掉。外部唤醒引脚如果需要打断睡眠，优先级可以设成高于 BASEPRI 的数值，比如 5，这样即使 FreeRTOS 关中断，外部中断也能正常唤醒。
4.3 用串口任务观察 tick 跳变是否连续
在调试阶段，用串口打印系统 tick 和空闲堆栈，能很快区分“时间没走”和“时间走错”：
void vTaskReport( void *pvParameters ) { for( ;; ) { printf( "tick=%lu free=%lu\r\n", ( unsigned long ) xTaskGetTickCount(), ( unsigned long ) xPortGetFreeHeapSize() ); vTaskDelay( pdMS_TO_TICKS( 1000 ) ); } }正常运行且无 Tickless 时，每秒打印的 tick 间隔是 1000。打开 Tickless 后，如果打印间隔变成 2000、3000，说明vTaskStepTick把睡眠时间重复计算了；如果间隔越来越大，说明睡眠时间没有被补回来。注意这个打印任务不能优先级太高，否则它自己会抢占 Idle，让 Tickless 永远进不去。
5. 想从 Tickless 进 Stop 模式：RTC 唤醒、时间补偿和 FreeRTOS 的边界
5.1 Sleep 和 Stop 在 Tickless 下的本质差别
SysTick 版 Tickless 只能稳定工作在 Sleep 模式，因为 SysTick 的计数时钟来自内核时钟域，Sleep 时时钟还在跑。Stop 模式下大部分时钟都停了，SysTick 不再计数，默认 port.c 醒来后读SysTick->VAL会得到错误结果。
| 比较项 | Sleep 模式 | Stop 模式 |
|---|---|---|
| Cortex-M4 内核时钟 | 停止 | 停止 |
| HCLK/PCLK 外设时钟 | 继续 | 停止 |
| SysTick 能否计数 | 能 | 不能 |
| FreeRTOS 时间补偿 | port.c 自动处理 | 需要 RTC/LPTIM 额外补偿 |
| F429 整板电流量级 | mA 级 | uA 级 |
进入 Stop 之前，要把 UART、DMA 这类容易产生总线访问的外设先 DeInit，否则醒来后总线状态不一致，串口第一字节经常乱码。
5.2 先做一遍 Stop 模式冒烟测试，不要直接改 port.c
在真正做 Tickless + Stop 之前，建议在一个普通任务里先验证 RTC 能定时唤醒、时钟能恢复。下面这段代码不是 Tickless 的完整方案，只是先把硬件链路打通：
void vStopDemoTask( void *pvParameters ) { for( ;; ) { vTaskDelay( pdMS_TO_TICKS( 5000 ) ); HAL_UART_DeInit( &huart3 ); __HAL_RTC_WAKEUP_EXTI_ENABLE_IT(); HAL_RTCEx_DeactivateWakeUpTimer( &hrtc ); HAL_RTCEx_SetWakeUpTimer_IT( &hrtc, 30000, RTC_WAKEUPCLOCK_CK_SPRE_16BITS ); HAL_PWR_EnterSTOPMode( PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI ); SystemClock_Config(); MX_USART3_UART_Init(); HAL_GPIO_TogglePin( LED_GPIO_Port, LED_Pin ); } }PWR_LOWPOWERREGULATOR_ON这个宏在不同 HAL 版本里可能叫PWR_REGULATOR_LOWPOWER，编译报错时先看stm32f4xx_hal_pwr.h。这段代码放在任务里，只能证明 Stop 模式能进能出。如果把它直接塞进空闲钩子，FreeRTOS 完全不知道 CPU 睡了 30 秒，所有vTaskDelay都会变成不可控的“睡过头”。
5.3 Tickless + Stop 真正要做的三件事
要把 Stop 和 Tickless 组合起来，核心不是 WFI，而是时间补偿。常见做法是在自定义的vPortSuppressTicksAndSleep里完成三件事：进 Stop 前关 SysTick 并记录 RTC 时间；醒来后恢复时钟；把实际睡眠时间换算成 tick 后调用vTaskStepTick。
uint32_t ulElapsedMs = GetRtcElapsedMs(); uint32_t ulElapsedTicks = ulElapsedMs / portTICK_PERIOD_MS; if( ulElapsedTicks > 0U ) { vTaskStepTick( ( TickType_t ) ulElapsedTicks ); }GetRtcElapsedMs()需要自己实现。最简单的时间基准是 RTC 的 SSR 子秒寄存器：进 Stop 前读一次，醒来后读一次，两次的差值按 RTC 时钟频率换算成毫秒。注意 RTC 的同步预分频值会影响 SSR 回绕周期，把PREDIV_S调成 32767，SSR 每 1 秒回绕一次，回绕计算会简单很多。
还有一个容易被忽略的边界：F429 的 RTC WakeUp Timer 自动重装载值只有 16 位，不是无限长。不要试图把xExpectedIdleTime整个塞进去，超过最大周期要分多次睡。
6. Tickless 工程的三件套：GPIO 测量窗、RTC 秒差校准和堆栈余量
6.1 用逻辑分析仪看 GPIO 高电平宽度
把configPRE_SLEEP_PROCESSING和configPOST_SLEEP_PROCESSING里的 GPIO 翻转让它们保持下来，然后用逻辑分析仪观察。高电平宽度就是单次实际睡眠时间。如果高电平宽度非常离散，说明有外部中断在随机打断睡眠；如果宽度恒定等于某个 93ms 整数倍，说明已经触发了 SysTick 24 位上限。
6.2 用 RTC 秒差验证系统时间
只靠 GPIO 看不出 FreeRTOS 时间是否正确，还需要一个外部时间基准。RTC 是最合适的，它在 Stop 模式下也走。跑一个对比任务：
RTC_TimeTypeDef sTime = { 0 }; void vTaskRtcCheck( void *pvParameters ) { for( ;; ) { vTaskDelay( pdMS_TO_TICKS( 60000 ) ); HAL_RTC_GetTime( &hrtc, &sTime, RTC_FORMAT_BIN ); printf( "rtc_sec=%lu tick=%lu\r\n", ( unsigned long ) sTime.Seconds, ( unsigned long ) xTaskGetTickCount() ); } }每 60 秒比对一次。如果 RTC 过了 60 秒而 tick 只走了 58 秒，说明 Stop 期间的时间补偿少了；如果 tick 走了 62 秒，说明重复补偿。调试阶段不要追求一次调准，先用这个对比判断方向。
6.3 不要漏掉 Idle 任务的堆栈余量
vPortSuppressTicksAndSleep和 PRE/POST 钩子都跑在空闲任务栈上，特别是 Stop 模式自定义实现里如果放了局部数组，Idle 任务栈会被吃掉很多。用 FreeRTOS 自带的栈高水位接口检查：
printf( "idle stack high water=%lu\r\n", ( unsigned long ) uxTaskGetStackHighWaterMark( xTaskGetIdleTaskHandle() ) );同时把configCHECK_FOR_STACK_OVERFLOW设为 2，并实现vApplicationStackOverflowHook。Tickless 移植最常见的隐性崩溃不是电流问题，而是空闲任务栈溢出后系统随机死机。RTC 闹钟最长周期只有 65535ms 时，超过这个值就分段睡，先睡 30 秒，剩下 30 秒再进一次，不要指望一次把xExpectedIdleTime全塞进 RTC 的 16 位寄存器。
本文还有配套的精品资源，点击获取
