STM32调用HAL库函数后while循环仅执行一次问题求助

• SysTick中断异常
  HAL_Delay完全依赖SysTick定时器的中断来更新全局计数变量uwTick，如果SysTick中断被关闭或被抢占无法执行，就会导致HAL_Delay内部的等待循环永远无法退出。
  排查动作：

  1. 检查代码中是否存在__disable_irq()调用后未执行__enable_irq()的情况，全局中断关闭会直接阻断SysTick中断。
  2. 在CubeMX中核对SysTick的中断优先级，默认是最低优先级（0x0F），如果有高优先级中断长期占用CPU（比如中断服务函数里有死循环、未及时退出），会导致SysTick中断无法触发。
  3. 手动在main()开头添加HAL_NVIC_EnableIRQ(SysTick_IRQn)，强制启用SysTick中断，验证是否恢复正常。

• 全局计数变量被破坏
  HAL_Delay的计时依赖uwTick和uwTickFreq两个全局变量，若其他代码存在非法内存访问（比如数组越界、野指针），可能会篡改这两个变量的值，导致延迟计算逻辑失效。
  排查动作：

  1. 在stm32fxx_hal.c中找到uwTick的定义，添加断点或串口打印，观察进入HAL_Delay前后该变量是否持续递增。
  2. 搜索整个项目，确认没有直接修改uwTick或uwTickFreq的代码，这两个变量属于HAL库内部维护的核心变量，禁止手动修改。
  3. 开启编译器的栈溢出检测和内存越界警告（比如Keil的--stackusage、GCC的-fsanitize=address），排查潜在的内存操作错误。

• 系统时钟配置错误
  如果系统时钟（SYSCLK）配置与实际硬件不符，SysTick的计数基准会出错，导致HAL_Delay的实际延迟远大于预期，表现为循环卡死。
  排查动作：

  1. 在CubeMX中重新生成时钟树配置，确保SYSCLK频率与代码中SystemCoreClock变量的值一致（可在SystemCoreClockUpdate()后打印该变量验证）。
  2. 检查HAL_InitTick()函数，确认SysTick的分频系数为SystemCoreClock / 1000，保证每1ms触发一次中断。
  3. 若硬件允许，用示波器测量SysTick输出引脚的脉冲频率，验证定时器是否按预期工作。

• 外设资源死锁
  若进入while循环前，有HAL外设操作未完成（比如DMA传输未结束、外设处于busy状态），调用HAL_Delay时可能触发隐性死锁。
  排查动作：

  1. 简化测试代码，仅保留while(1){counter++; HAL_Delay(100); printf("%d\n", counter);}，确认基础逻辑是否正常。
  2. 逐步添加其他外设初始化代码，定位到导致卡死的具体模块，检查该外设的HAL函数调用是否正确释放资源。
  3. 替换HAL_Delay为简单的空循环延迟（比如for(uint32_t i=0; i<1000000; i++);），若循环恢复正常，说明问题确实出在HAL_Delay的依赖逻辑上。

内容的提问来源于stack exchange，提问作者Enes