STM32F429 定时器触发 USART DMA 传输问题

Posted 2023-02-19

【中文标题】STM32F429 定时器触发 USART DMA 传输问题

【英文标题】：STM32F429 Timer triggered USART DMA transfer issue

【发布时间】：2015-07-06 17:40:18

【问题描述】：

这是我在这个论坛的第一篇文章。 我正在开发一个基于 STM32F429DISCOVERY 板的 MIDI 音序器设备，该板运行频率为 180MHz。为了发送 midi 消息，USART1 被配置为 31250 波特，并且适当的 DMA 被配置为将存储在 ram 中的 3 字节数组传输到 USART。我正在通过配置 Timer 4 更新中断来测试发送 midi 消息的时间，在该服务例程中我启用了 memory-to-peripheralUSART1 DMA 操作。这使我可以通过 USART1 外设定期发送 3 字节消息。

一切都很好，并且频率和数据都正确，但是我有一个小问题，我已经研究了几天并且无法纠正。为了让事情更清楚，在定时器中断例程中，我将发现 (RG13) 上的 LED 设置为暂时闪烁并将示波器的 1 个通道连接到 LED 引脚。示波器的第二个通道连接到 USART TX 引脚。现在，当代码执行时，我可以看到示波器 CH1 上的 LED 脉冲，然后是 CH2 上的 USART 串​​行数据。但是由于某种原因，LED 脉冲和串行数据传输开始之间的时间会随着每次发送数据而波动。它随着每次发送而增加，从大约 1uS 到大约 30uS，然后跳回到 1。 我注意到，如果我稍微改变 USART 波特率，脉冲和数据发送之间的时间波动就会改变模式，变快或变慢，范围更长或更短。 我尝试从 USART 和 DMA 重置所有适当的标志，尝试禁用/启用定时器，使用中断优先级，但没有任何方法可以消除时间波动。 正如您所想象的那样，它的稳定性对于 MIDI 音序器硬件应用程序至关重要，因为它基于音乐事件的时序，而音乐事件的时序必须坚如磐石。 我也尝试过在没有 DMA 的情况下单独使用 USART，手动发送每个字节，结果基本相同。中断驱动的 USART TX 表现出同样的结果。 唯一似乎可以消除 USART TX 响应时间波动的方法是，在每次发送操作之前取消初始化 USART 和 DMA 模块并重新初始化它们。这似乎提供了稳定的操作，但在定时器中断和通过 USART 实际发送数据之间插入了很长的延迟，这是不可接受的。

如果有人对此有任何想法或做过类似的事情，我需要关于在哪里查看的建议。

提前非常感谢！

最好的问候， 康斯坦丁

【问题讨论】：

欢迎来到 ***。大多数“常客”都有一个他们密切监视的标签列表，而您的标签看起来都不是特别常见……使用操作系统或编程语言进行标签可能会让您的问题得到更多关注。祝你好运:-)

【参考方案1】：

即使根据您的详细描述，错误的可能性也有很多，所以我能做的就是猜测：

也许只是其中一个 TIM 设置有点错误：定时器的自动重载寄存器 (TIM4_ARR) 怎么样？

周期设置必须比所需的传输周期除以（可能预分频）时钟周期（参见详细的向上计数/向下计数规范）。

现在，如果重新加载值只是 等于 到该值，则第二次触发将延迟一小段时间，第三次触发将延迟两倍等等（这可能看起来像你描述的）。 然后，这种“延迟斜坡”会上升，直到不需要的延迟总和达到一个 UART 位周期（对于 31250 波特，恰好是 32uS，非常接近您描述的“大约 30uS”）。下一个触发器将恰好适合相邻的 UART 位周期（没有太多延迟）。

将此假设与您的其他发现进行比较...

更改 UART 波特率将保留基本错误，但令人讨厌的延迟持续时间会发生变化。它可能会改变其符号（“更快或更慢”），具体取决于（实际）TIM 周期和 UART 位周期之间的节拍特性。 => 好的

将事件处理从 DMA 更改为 IRQ 处理程序不会对问题有太大改变，而只会改变初始延迟的“阶段”（当 CPU 需要执行不同的 ST 库函数时）。 => 好的

禁用和重新启用 UART 可能会改变行为，因为 UART 时钟可能会重新与底层总线时钟（USART2 的 APB2）重新同步，因此 TIM 触发后的延迟看起来是恒定的，并且你不会注意到波动。 => 好的

【讨论】：

根据我的回答，我参加聚会有点晚了，但也许你在阁楼的某个角落找到了旧代码，或者它可以帮助其他人......