请选择 进入手机版 | 继续访问电脑版
搜索
查看: 174|回复: 1

[原创] DMA触发请求异常之案例分享

[复制链接]

该用户从未签到

13

主题

32

帖子

0

蝴蝶豆

初级会员

最后登录
2018-4-24
发表于 2020-2-18 11:44:40 | 显示全部楼层 |阅读模式
某STM32用户开发产品,用到ADC模块,通过定时器更新事件触发AD转换,转换结果由DMA搬运到指定的内存区域。DMA工作在正常模式(即非循环模式),每当传输完毕一批数据后在传输完成中断里设置传输结束标志,应用代码对该标志进行监视。

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

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

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

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

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

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

11.jpg

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

22.jpg

配置完毕后生成初始化代码,然后添加用户代码。
这里准备了几个内存变量.

33.jpg

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

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

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

44.jpg

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

55.jpg

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

66.jpg

那客户反馈的情况到底是怎么回事呢?
因为没见到用户具体的代码,他说过在DMA做完第一次传输后,还对定时器做了复位。那我们不妨在第一次DMA传输结束后,增加对定时器的复位操作,看看结果会怎么样。

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

77.jpg

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

88.jpg

当然,单纯从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标志的清除。【下图中的第二个红圈内的代码】

99.jpg

难道说这个清除EOC标志的操作有问题?
先确认代码写法本身,没有问题。再看逻辑和时序上问题。
通过进一步的调试,在下图所示代码处放了3个断点单步运行,的确发现定时器复位事件触发了ADC转换,EOC被置位。在后续代码中也发现EOC被清零了。有意思的是,当开着下图所示3个断点来运行时,那个奇怪的现象就消失了,那潜伏的DMA请求似乎遁形了。

10.jpg

如果取消上面的第1、第2个断点后运行代码,那个现象立即又重现,潜伏的又激活了。
反复验证到这里,基本上明白是怎么回事了。

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

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

111.jpg

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

222.jpg

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

333.jpg

1、针对STM32定时器的软件复位操作可以产生更新事件,其效果等同于定时器溢出导致的更新事件。
2、我们编写代码,尤其这种嵌入式代码时,除了保证代码基本的正常逻辑外,各个硬件本身操作时序、响应时间参数等也须多加关注。
3、结合本案例,在第一次DMA传输完成后为第二次DMA做准备时,建议先关闭计数器,否则可能会给我们的应用带来些隐患,本案例中探讨的问题,就是其中隐患之一。限于篇幅和主题,这里就不啰嗦了,后面若有合适案例再行交流。


回复

使用道具 举报

该用户从未签到

31

主题

380

帖子

59

蝴蝶豆

金牌会员

最后登录
2020-4-3
发表于 2020-2-20 09:45:08 | 显示全部楼层
感谢楼主的分享
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|论坛-意法半导体STM32/STM8技术社区

GMT+8, 2020-4-6 23:39 , Processed in 0.095594 second(s), 15 queries , MemCache On.

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表