前两天在一个H745的项目上被一个"玄学"问题卡了一晚上：程序在上电全速运行时一切正常，但只要在调试器里加一个断点、或者在某个函数里单步执行，就会死死卡在非常靠前的初始化流程里，具体位置停在HAL_Delay()的 while 循环中。更离谱的是这个阶段连外设都还没初始化，时钟也还是复位后的默认状态，按理说这里是最不该出问题的地方。折腾到后来我才意识到，这个问题的根子不在代码逻辑，而在 Cortex-M 的调试机制和 SysTick 时间基准的配合上。
这个现象在 STM32H745XI 这类双核高性能 MCU 上尤其常见，很多人会误以为自己踩了硬件坑、电源坑，甚至怀疑芯片坏了。其实只要理解了 HAL_Init()、HAL_Delay() 和调试器三者之间的关系，这个问题可以在十分钟内定位清楚。这篇文章就把完整的排查链路、原因分析和解决方案写出来，给后续遇到同样问题的人一个参考。
1. 现象定位：先搞清楚你是哪种"卡死在HAL_Delay()"
遇到问题先别急着改代码，先花两分钟确认你属于哪一种现象。我见过很多相似的问题，实际上"卡死"的触发点根本不同，排查方向也完全不一样。
1.1 最典型的场景：全速正常，一碰断点或单步就死
这是最多人遇到的情况。全速运行时程序跑得飞起，串口正常打印，外设正常翻转，但只要你在任意一个地方设个断点，或者用 Step Over 单步走几步，程序就停在一个"回不来"的状态。你再次按全速运行，它仍然卡死，只能重新复位。
在调试器里暂停下来，Call Stack 会指向HAL_Delay()内部的 while 循环，而且看起来像是从很前面的初始化流程调进来的。
这种场景下，程序本身没有问题，纯粹是"调试器的暂停动作"把时间基准给冻结了。Cortex-M 在调试暂停时，默认会把 SysTick 定时器一起暂停，而HAL_Delay()恰恰完全依赖 SysTick 中断来推进时间，于是你在 while 循环里等一个永远也不会到来的时刻。
1.2 第二种场景：复位后一全速就卡，从头到尾没正常过
这种情况下，你从 Debug 一启动，程序就很快进入HAL_Delay()并且永远出不来。拔掉调试器，板子单独上电也一样卡死。
那这基本可以排除调试暂停的因素，核心问题出在 SysTick 根本没有跑起来，或者跑起来了但中断进不去。常见的原因有几个：
HAL_Init()里的HAL_InitTick()没有正确配置 SysTick；- 全局中断被意外关闭了，SysTick 的 tick 中断无法触发；
- 时钟树配置有问题，SysTick 的时钟源异常；
- 启动阶段就触发了某类异常，导致 CPU 陷入 HardFault，而你在 HardFault 里又调用了延时。
注意第三种可能。我见过有人在HardFault_Handler里加串口打印和延时，结果每次 HardFault 一进来就卡死在延时里，看起来像是"初始化时卡死"，实际上是异常处理程序里的延时把问题掩盖了。
1.3 第三种场景：某个外设初始化后卡死
还有一类情况，程序能跑过HAL_Init()，能跑过SystemClock_Config()，但在初始化某个外设之后、或者第一次调用HAL_Delay()时卡死。这种问题的根源通常不在 SysTick 本身，而是之前某一步把中断环境破坏了。
比较典型的是：你在外设初始化里调用了__disable_irq()但没配__enable_irq()，或者某个外设中断优先级设置得太高/太低，把 SysTick 的中断抢占了。H7 系列的中断数量多，NVIC 配置也比较复杂，这一步很容易埋伏笔。
另一种常见情况是，代码里手动操作了SysTick->CTRL或SysTick->LOAD，把 HAL 库的 1ms 配置改掉了，比如清零了 ENABLE 位或改成了不产生中断的模式。一旦 SysTick 中断不再触发，HAL_Delay()就是一个死循环。
2. 拆开HAL_Init()：时间基准为什么这么脆弱
要真正解决这个问题，得先搞清楚HAL_Init()这个函数到底做了哪些事，以及HAL_Delay()依赖的那个"时间"是从哪来的。很多人只知道"调用 HAL_Init 就能用 HAL 库了"，但里面每一步之间的先后关系并没细看。
2.1 HAL_Init()到底做了什么
以 H745 的 HAL 库为例，HAL_Init()执行的事情大致是：
- 配置 Flash 预取缓冲和指令/数据 Cache（H7 上这是可选的，由宏控制）；
- 设置 NVIC 优先级分组，默认
NVIC_PRIORITYGROUP_4； - 调用
HAL_InitTick()初始化 SysTick，让它每 1ms 产生一次中断； - 调用
HAL_MspInit()做 MCU 底层硬件初始化。
关键在第三步。HAL_InitTick()__weak函数会读取当前的系统时钟频率，计算出 SysTick 的重装载值，使 SysTick 以 1ms 为周期产生中断。它还会设置 SysTick 中断优先级，并直接使能 NVIC 中的 SysTick 中断。
注意一个容易忽略的点：HAL_Init()执行时，SystemClock_Config()可能还没被调用，所以HAL_InitTick()用的是复位后的默认系统时钟来配置 SysTick。如果你在 main 里先调HAL_Init()，后调SystemClock_Config()，那么切换时钟后 SysTick 的周期就不再是标准的 1ms，HAL_Delay()的延时长度也会跟着变。这不是本文说的"卡死"，但它是另一个和 SysTick 相关的经典坑，后面再说。
2.2 HAL_Delay()的依赖链：uwTick与SysTick_Handler
HAL_Delay()的实现非常朴素：
__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()的返回值，而HAL_GetTick()读的是一个全局变量uwTick。uwTick只在 SysTick 中断处理函数里递增，CubeMX 生成的代码中是：
void SysTick_Handler(void) { HAL_IncTick(); }所以整条链路是：SysTick 定时器产生中断 → 进入SysTick_Handler()→ 调用HAL_IncTick()→uwTick++→HAL_Delay()的 while 循环才能跳出。
这条链路的任何一个环节断裂，HAL_Delay()都会永久卡死。这也是为什么HAL_Delay()在"程序逻辑上"看起来那么简单，却非常容易出问题的原因。它不是一个硬件定时器轮询，而是一个中断驱动的软件延时。
2.3 调试暂停时，Cortex-M发生了什么
现在回到"调试暂停导致卡死"这个核心机制。
Cortex-M 内核在做 Debug Halt 时，也就是你把程序暂停下来准备看变量的时候，默认会停止正在运行的程序。与此同时，和处理器强相关的定时器也会被冻结，SysTick 就是一个典型的例子。ArM v7-M 架构中，当内核被调试器暂停，SysTick 的计数器默认不会再往下数，DWT 的周期计数器同样会停。
这就导致
