一、问题现象与背景

在STM32开发中，许多开发者习惯使用HAL库提供的HAL_Delay()函数实现毫秒级延时。然而，当在中断服务程序（ISR）中调用HAL_Delay()时，系统可能陷入死锁，表现为程序卡死在延时函数内，看门狗复位或系统无响应。本文将从原理层面分析该问题的成因，并提供三种可靠的替代延时方案。

二、HAL_Delay的实现机制

HAL_Delay()的核心依赖于SysTick定时器中断。其简化实现如下：

__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，该变量在SysTick中断服务函数SysTick_Handler()中递增：

void SysTick_Handler(void)
{
  HAL_IncTick();  // uwTick++
}

三、死锁成因分析

死锁发生的根本条件是：在中断上下文中调用HAL_Delay()，且该中断的优先级高于或等于SysTick中断的优先级。

3.1 中断优先级与抢占机制

Cortex-M内核中，高优先级中断可以抢占低优先级中断。SysTick中断通常配置为最低优先级（数值最大），以确保系统节拍不会打断其他关键中断。若用户中断的优先级数值小于或等于SysTick优先级（即优先级更高或相等），则：

当用户中断正在执行时，SysTick中断无法抢占（若优先级相等，则无法嵌套）。
此时若在用户ISR中调用HAL_Delay()，uwTick不会递增，HAL_GetTick()始终返回相同值，while循环永不退出，形成死锁。

3.2 死锁条件总结

在ISR中调用HAL_Delay()。
该ISR的优先级高于或等于SysTick中断优先级。
SysTick中断被屏蔽或无法抢占当前ISR。

四、替代延时方案

为避免死锁，在中断上下文中应使用不依赖系统节拍的延时方法。以下提供三种方案。

4.1 方案一：基于DWT周期计数器的精确延时

Cortex-M3/M4/M7内核包含数据观察点与跟踪单元（DWT），其CYCCNT寄存器记录内核时钟周期数。通过读取CYCCNT可实现高精度延时，且不依赖中断。

配置步骤：

使能DWT和CYCCNT：

void DWT_Init(void)
{
  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
  DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
  DWT->CYCCNT = 0;
}

实现微秒级延时（假设系统时钟为168MHz）：

void DWT_DelayUs(uint32_t us)
{
  uint32_t start = DWT->CYCCNT;
  uint32_t ticks = us * (SystemCoreClock / 1000000);
  while ((DWT->CYCCNT - start) < ticks);
}

毫秒级延时：

void DWT_DelayMs(uint32_t ms)
{
  while (ms--)
  {
    DWT_DelayUs(1000);
  }
}

优点： 精度高，不依赖中断，可在ISR中安全使用。 注意： 需确保DWT初始化在系统启动后尽早完成；不同内核支持情况需查阅参考手册。

4.2 方案二：基于硬件定时器的单次延时

利用一个基本定时器（如TIM6）产生单次延时，通过轮询标志位实现。

配置步骤（以TIM6为例）：

初始化定时器，预分频器设置为系统时钟/1MHz-1，计数器周期根据延时动态设置。

void TIM6_DelayInit(void)
{
  __HAL_RCC_TIM6_CLK_ENABLE();
  TIM6->PSC = (SystemCoreClock / 1000000) - 1;  // 1MHz计数频率
  TIM6->CR1 |= TIM_CR1_OPM;  // 单次模式
}

void TIM6_DelayUs(uint32_t us)
{
  TIM6->CNT = 0;
  TIM6->ARR = us - 1;
  TIM6->EGR = TIM_EGR_UG;  // 更新寄存器
  TIM6->CR1 |= TIM_CR1_CEN;
  while (!(TIM6->SR & TIM_SR_UIF));
  TIM6->SR &= ~TIM_SR_UIF;
}

优点： 不占用CPU空转（可结合中断），精度较高。 注意： 需独占一个定时器；在ISR中轮询时仍会占用CPU时间。

4.3 方案三：基于空循环的粗略延时

对于时间精度要求不高的场景，可使用空循环延时，但需注意编译器优化。

void Rough_Delay(volatile uint32_t count)
{
  while (count--)
  {
    __NOP();
  }
}

优点： 简单，不依赖任何外设。 缺点： 精度差，受编译器和主频影响，需实测校准。

五、注意事项

避免在ISR中调用HAL_Delay：这是最根本的原则。若必须延时，请使用上述替代方案。
合理配置中断优先级：确保SysTick优先级最低，避免其他中断阻塞系统节拍。
DWT延时需考虑内核支持：Cortex-M0/M0+无DWT，需改用其他方案。
定时器方案注意资源冲突：避免使用已被占用的定时器。
空循环延时需使用volatile变量：防止编译器优化掉循环。
在RTOS环境中：应使用RTOS提供的延时函数（如osDelay），但同样不能在ISR中调用。

六、总结

HAL_Delay()在中断上下文中死锁的根源在于其依赖SysTick中断更新时基，而高优先级ISR会阻塞SysTick。通过分析中断优先级机制，我们明确了死锁条件。本文提供的DWT周期计数延时、硬件定时器延时和空循环延时三种方案，均可有效规避该问题。开发者应根据精度需求、资源占用和内核特性选择合适方案，并始终遵循“不在ISR中调用阻塞式延时”的编程规范。

STM32 HAL库中HAL_Delay在中断上下文调用导致死锁的成因与替代延时方案