STM32 HAL库中uwTickFreq异常归零，导致HAL_Delay()死循环的排查与解决实录

1. 问题现象：HAL_Delay()为何突然卡死？

最近在调试STM32项目时，遇到一个让人头疼的问题：程序运行一段时间后，整个系统就像被冻住一样毫无反应。通过Keil的调试器单步跟踪，发现程序卡在了HAL_Delay()函数内部。这个函数本应实现毫秒级延时，现在却变成了死循环。

具体现象表现为：

• 串口通信时数据发送过快会出现乱码，必须依赖HAL_Delay()做间隔控制
• 问题随机出现，有时运行几分钟就卡死，有时能正常工作几小时
• 调试时发现HAL_GetTick()返回值停止更新，导致while循环条件永远成立

这个问题特别具有迷惑性，因为：

1. 硬件定时器配置看起来完全正常
2. 同样的代码在其他项目中运行良好
3. 没有明显的内存溢出或堆栈异常

2. 深入HAL库：揭开延时函数的秘密

2.1 HAL_Delay()的工作原理

先来看标准HAL库的实现（以STM32F1系列为例）：

c复制__weak void HAL_Delay(uint32_t Delay)
{
  uint32_t tickstart = HAL_GetTick();
  uint32_t wait = Delay;
  
  if (wait < HAL_MAX_DELAY) {
    wait += (uint32_t)(uwTickFreq);
  }
  
  while ((HAL_GetTick() - tickstart) < wait) {
    /* 空循环等待 */
  }
}

关键点在于：

• HAL_GetTick()返回系统时钟节拍计数值uwTick
• uwTick由SysTick中断服务程序通过HAL_IncTick()递增
• uwTickFreq决定每次递增的步长

2.2 关键变量追踪

继续深入底层，发现三个关键组件：

1. uwTick：全局时钟节拍计数器

   c复制__weak uint32_t HAL_GetTick(void) {
     return uwTick;
   }
   

2. uwTickFreq：节拍频率系数

   • 默认值HAL_TICK_FREQ_DEFAULT=1
   • 影响延时精度和计算方式