使用FreeRTOS时DMA完成后未调用HAL_TIM_PWM_PulseFinishedCallback问题

你遇到的问题核心是FreeRTOS的中断优先级管控机制和HAL库中断配置不匹配，导致DMA传输完成后的TIM中断无法触发回调，进而DMA持续重复发送最后一组数据。以下是具体的解决方法：

1. 调整TIM和DMA的中断优先级 #

FreeRTOS通过configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY（在FreeRTOSConfig.h中定义）限制了能调用内核API的最高中断优先级，优先级数值大于该值的中断会被调度器屏蔽（STM32中优先级数值越小，实际优先级越高）。

需要将TIM4和对应DMA通道的中断优先级设置为数值小于等于configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY：

// 示例：在初始化代码中配置中断优先级
HAL_NVIC_SetPriority(TIM4_IRQn, 4, 0);
HAL_NVIC_SetPriority(DMA1_Stream2_IRQn, 4, 0); // 替换为你实际使用的DMA通道

同时检查FreeRTOSConfig.h中的配置，比如：

#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

确保你设置的TIM/DMA优先级数值（比如4）小于等于这个值。

2. 确认DMA传输完成中断已开启 #

有时在FreeRTOS环境下，HAL库的初始化逻辑可能未正确开启DMA的传输完成（TC）中断，手动补充开启：

// 在调用HAL_TIM_PWM_Start_DMA之前添加
__HAL_DMA_ENABLE_IT(&hdma_tim4_ch3, DMA_IT_TC);

3. 验证TIM中断是否正常触发 #

可以在TIM4的中断服务函数中添加调试标记，确认中断是否被触发：

void TIM4_IRQHandler(void)
{
  // 这里可以加串口打印或LED翻转等调试操作
  HAL_TIM_IRQHandler(&htim4);
}

如果中断根本没进入，说明优先级配置还是有问题，或者中断未正确使能。

4. 避免任务抢占导致中断响应延迟 #

如果启动DMA的任务优先级过低，被高优先级任务长时间抢占，会导致DMA传输完成后中断无法及时响应。可以给启动DMA的任务设置合适的优先级，或者确保高优先级任务不会长时间占用CPU。

为什么超级循环下正常？ #

超级循环没有中断优先级的管控机制，所有中断都能不受限制地响应，而FreeRTOS的优先级限制是为了防止高优先级中断打断内核关键操作，保证系统稳定性，这也是两者行为差异的根本原因。

内容的提问来源于stack exchange，提问作者Ondřej Dušek