DMA+Timer 生成 PWM 波形错位问题分析与解决-平芜编程栈

1. PWM波形错位问题现象解析

第一次用逻辑分析仪抓取WS2812驱动信号时，我盯着屏幕上的波形愣住了——明明数组里定义了48个PWM周期，示波器上却固执地显示着49个脉冲。更诡异的是，第一个脉冲的占空比竟然对应的是数组第二个元素的值，就像有个看不见的手把整个波形序列往右推了一格。

这个问题在LED控制场景中尤为致命。想象你正在制作一个LED灯带动画，每个PWM周期对应一个LED的亮度值。当波形整体错位时，原本设计好的流光效果就会变成混乱的闪烁，就像交响乐团里所有乐手都错位演奏了下一个音符。

通过简化测试代码，我排除了数据填充函数的干扰，直接用硬编码数组测试：

uint16_t test_arr[48] = { 59,29,59,59,59,59,59,59, 29,29,29,29,29,29,29,29, // ... 后续数据省略 }; HAL_TIM_PWM_Start_DMA(&htim1, TIM_CHANNEL_1, (uint32_t *)test_arr, 48);

逻辑分析仪捕获到的波形序列却变成了：29,59,29,59,59... 这个现象让我意识到，问题出在DMA和定时器的协作机制上，而不是简单的代码错误。

2. 根本原因深度剖析

2.1 DMA与定时器的时序博弈

问题的核心在于DMA传输启动时机与定时器溢出中断的微妙关系。当调用HAL_TIM_PWM_Start_DMA()时，硬件会经历以下关键步骤：

定时器开始运行，自动产生第一个溢出中断
该中断触发DMA请求
DMA开始搬运第一个数据（test_arr[0]）
定时器比较器更新为新值

但问题在于，在DMA完成第一次传输前，定时器已经用默认值产生了第一个PWM脉冲。这就解释了为什么我们会看到"多余"的那个脉冲——它其实是定时器自主产生的"开机第一拍"。

2.2 中断服务程序的盲区

通过调试发现，当DMA传输完成中断被调用时，DMA控制器其实已经搬运到第二个数据了。这意味着：

void HAL_TIM_PWM_PulseFinishedCallback(TIM_HandleTypeDef *htim) { // 此时CCR寄存器已经被更新为test_arr[1]的值 }

这个现象在STM32的参考手册中有迹可循：DMA传输是异步进行的，而中断响应存在延迟。在高速PWM场景下（比如WS2812需要800kHz信号），这种延迟足以让DMA提前完成多次传输。

3. 实战解决方案

3.1 占空比强制清零法

最直接的解决方案是在DMA传输完成后立即重置占空比：

void HAL_TIM_PWM_PulseFinishedCallback(TIM_HandleTypeDef *htim) { __HAL_TIM_SET_COMPARE(&htim1, TIM_CHANNEL_1, 0); HAL_TIM_PWM_Stop_DMA(&htim1, TIM_CHANNEL_1); }

这个方法相当于给PWM波形加了个"终止符"，确保不会产生多余的脉冲。实测在WS2812驱动场景下，这种方法能完美解决数据错位问题。

3.2 预装载值调校技巧

更优雅的做法是利用定时器的预装载功能：

在CubeMX中使能TIMx_CR1寄存器的ARPE位
初始化时将第一个占空比设为0
在DMA配置中将源地址偏移+1，长度-1

// 初始化配置 TIM1->CR1 |= TIM_CR1_ARPE; __HAL_TIM_SET_COMPARE(&htim1, TIM_CHANNEL_1, 0); // DMA配置调整 HAL_TIM_PWM_Start_DMA(&htim1, TIM_CHANNEL_1, (uint32_t *)&test_arr[1], 47);

4. 进阶问题排查手记

4.1 神秘的数组越界现象

在调试过程中，我还遇到一个更诡异的案例：即使调用了停止DMA的函数，仍然会出现多余波形。最终发现这与中断服务程序中的计数器操作有关：

volatile int cnt = 0; void HAL_TIM_PWM_PulseFinishedCallback(TIM_HandleTypeDef *htim) { cnt++; if(cnt == 2) { cnt = 0; HAL_TIM_PWM_Stop_DMA(&htim1,TIM_CHANNEL_1); __HAL_TIM_SET_COMPARE(&htim1,TIM_CHANNEL_1,0); } }

问题根源在于：

中断服务程序中的变量操作影响了堆栈
大数组（192个元素的pulse[]）导致内存边界异常
删除未使用的全局数组后问题消失

4.2 DMA长度参数陷阱

不同STM32系列对DMA长度参数的解释不同：

STM32F4/G0系列：表示传输数据项数
STM32U5系列：表示传输字节数

这会导致同样的代码在不同平台表现不同。例如对于16位数据：

// STM32F4正确配置 HAL_TIM_PWM_Start_DMA(&htim1, TIM_CHANNEL_1, (uint32_t *)data, 48); // STM32U5需要调整为 HAL_TIM_PWM_Start_DMA(&htim1, TIM_CHANNEL_1, (uint32_t *)data, 48*2);