DMA触发请求异常之案例分享

某STM32用户开发产品，用到ADC模块，通过定时器更新事件触发AD转换，转换结果由DMA搬运到指定的内存区域。DMA工作在正常模式（即非循环模式），每当传输完毕一批数据后在传输完成中断里设置传输结束标志,应用代码对该标志进行监视。

当检查到该有效标志时，说明采集到了预定的转换数据。将数据处理后，软件产生TIMER更新事件,以保证计数器从0开始计数【注：这里选用的向上计数模式】。然后清除更新事件标志、ADC转换完成标志位EOC ，关闭DMA后对DMA进行再配置，然后重新使能DMA进行第二次传输。

调试中发现，对于第二次DMA传输，每次一使能DMA 就立即搬运一个数据。按理说应该延时一个定时器更新周期后才会搬运首次数据才对。因为软件置位UG位后，用来触发ADC的TIMer是从0开始计数的，需要计数到溢出才会触发AD转换。他想不明白的是TIM已经复位从0开始计数了，该清的标志位都清除了，还有什么原因导致DMA不等TIMER触发就立即先行搬运一个数据呢。

该问题源于某STM32论坛，但用户没有贴出任何代码。这里模拟他的应用场景做个测试验证，并试图找出相关原因。

我这里也设计了两轮DMA传输，照样使用TIMER更新事件触发ADC转换。第一轮DMA传输传输3个AD转换结果到某内存地址，第二轮传输5个转换结果到另一内存位置。

先使用Stm32CubeMx基于STM32F411Discovery板进行基本的初始化配置。配置都很简单。

ADC配置，这里只选择1个常规通道用于测试，选择TIM2的触发输出启动AD转换，并开启ADC的DMA传输功能，DMA工作在Normal模式。【硬件上ADC输入通道我直接连VDD了】

TIMER配置，这里选择TIM2，其更新事件做为触发输出用来启动ADC。

配置完毕后生成初始化代码，然后添加用户代码。

这里准备了几个内存变量.

我在第一次DMA传输完成后立即关闭定时器，在开启第二轮DMA传输前，不让定时器有机会再次触发ADC产生EOC事件。看看有无他说到的情形发生。

我把用户代码分成两部分，分别用红框、绿框区分。

第一部分由基本的初始化函数、开启ADC外设及其DMA功能、对第一次DMA传输做配置并使能DMA、等待3次ADC转换结束。

第二部分代码的功能主要关闭定时器、关闭DMA,第二次对DMA进行配置，再开启DMA功能并启动定时器。【我把断点打在箭头所指的地方，即待启动计数器的那句代码处】

基于上述代码测试，没有发现一使能第二次DMA传输就先传一个数据的现象。这时定时器也没被启动，DMA处于就绪待命状态。【结果如下图】

那客户反馈的情况到底是怎么回事呢？

因为没见到用户具体的代码，他说过在DMA做完第一次传输后，还对定时器做了复位。那我们不妨在第一次DMA传输结束后，增加对定时器的复位操作，看看结果会怎么样。

我将第二部分代码稍作修改如下【见下图中A处代码】:

基于调整过的代码进行测试，还真发现了一使能第二次DMA传输时就先传一个数据的现象。可是此时定时器仍未启动，DMA怎么就开始传输数据了呢。【结果如下图所示】

当然，单纯从DMA传输功能来讲，它跟定时器是否启动并没有必然联系。对于被使能了的DMA，只要有合适的DMA请求出现，它就行使职能。具体到这里，应该是有EOC事件出现了才会发生DMA传输的。那这个EOC事件从哪里来的呢？

我们不妨先理一理：

第一次DMA传输完成后不可能还有待处理EOC事件存在。在第一次DMA传输过程中，每次DMA读取ADC数据就保证EOC被清零了，DMA传输完成后又立即关闭了定时器，本案例里也没有别的事情影响定时器的迅速关闭。按理说在两次DMA传输之间不会有定时器更新事件触发AD转换，更何况在使能第二次DMA前还专门做了EOC的清除操作。

看起来的确有点奇怪，怎么感觉有个DMA请求，用客户的话说，好像潜伏在哪里一样？

目前的代码跟刚开始的比，多了个定时器的复位操作。难道这个复位操作会导致ADC转换而生成EOC事件？说到这，它还真有这本事。

因为软件方式对定时器进行复位也可以产生更新事件，它正好能启动AD转换【AD转换功能一直都没关闭过】从而产生EOC事件。如果EOC标志没有及时清除的话，就可以在下次DMA传输刚被使能，即使计数器还没被启动的条件下触发一次DMA传输。

分析到这里，感觉找到问题原因了。但是，似乎还是有点不对劲。因为即使定时器复位动作产生更新事件而触发ADC转换，进而产生EOC事件， 但我们在定时器复位动作之后还特意做过对EOC标志的清除。【下图中的第二个红圈内的代码】

难道说这个清除EOC标志的操作有问题？

先确认代码写法本身，没有问题。再看逻辑和时序上问题。

通过进一步的调试，在下图所示代码处放了3个断点单步运行，的确发现定时器复位事件触发了ADC转换，EOC被置位。在后续代码中也发现EOC被清零了。有意思的是，当开着下图所示3个断点来运行时，那个奇怪的现象就消失了，那潜伏的DMA请求似乎遁形了。

如果取消上面的第1、第2个断点后运行代码，那个现象立即又重现，潜伏的又激活了。

反复验证到这里，基本上明白是怎么回事了。

毫无疑问，定时器的复位操作导致AD转换而产生了EOC事件。代码里虽然有对EOC的清除操作，但该操作相对ADC而言，太早了点。即在针对EOC做删除操作时，ADC可能还在忙着转换，离产生EOC事件还早呢。这正好可以解释为什么在复位操作代码后放个断点再删除EOC就有效的情形。

既然这样，我在清除EOC操作代码的前面加一句EOC标志查询等待，以保证后续的清除操作可靠有效。我将代码再次做了调整。见下图中方框内代码。

就修改过的代码进行验证，那个现象彻底消失。后续的第二轮DMA传输也规规矩矩了。

到此，本应用案例分享结束。最后，稍作小结并做些提醒：

1、针对STM32定时器的软件复位操作可以产生更新事件，其效果等同于定时器溢出导致的更新事件。

2、我们编写代码，尤其这种嵌入式代码时，除了保证代码基本的正常逻辑外，各个硬件本身操作时序、响应时间参数等也须多加关注。

3、结合本案例，在第一次DMA传输完成后为第二次DMA做准备时，建议先关闭计数器，否则可能会给我们的应用带来些隐患，本案例中探讨的问题，就是其中隐患之一。限于篇幅和主题，这里就不啰嗦了，后面若有合适案例再行交流。