{"answer":"根因：HAL_Delay基于SysTick中断维护的uwTick全局变量做忙等，其内部循环依赖SysTick中断持续递增uwTick。当在中断上下文中调用时，若该中断优先级高于或等于SysTick（通常SysTick为最低优先级），SysTick中断无法抢占当前ISR，uwTick不再更新，HAL_Delay陷入永久等待，形成死锁；即使优先级允许抢占，长延时也会严重阻塞中断响应。此外HAL_Delay内部未做重入保护，多上下文调用存在竞态。替代方案：1) 中断中绝对禁止阻塞延时，改用状态机+时间戳非阻塞方式，在主循环中判断超时；2) 需要短延时时使用DWT周期计数器或硬件定时器做忙等，不依赖SysTick；3) 用独立硬件定时器产生单次中断或标志位实现异步延时；4) 若必须同步等待，可临时提升SysTick优先级（不推荐，破坏实时性）。实操建议：代码审查中禁止在ISR及回调中调用HAL_Delay，用静态分析或宏重定义在调试版中拦截。","extras":[{"content":"本质是优先级反转：SysTick被高优先级ISR屏蔽，uwTick冻结。建议在FreeRTOS下用vTaskDelay或xTaskGetTickCount，中断里只置标志。","author":"嵌入式老张"},{"content":"可把HAL_Delay替换为基于DWT->CYCCNT的忙等，精度高且不依赖中断，但仅适合微秒级短延时，长延时仍应状态机化。","author":" CortexM小兵"},{"content":"调试时可在HAL_Delay入口加断言检查IPSR寄存器非零即报错，快速定位ISR误用，比事后排查死锁高效。","author":"硬件萌新"}],}