STM32 DMA传输的问题分析

描述

问题1、

用户使用STM32G473RET6芯片,开发环境STM32CubeMX+Keil(LL库)。使用DMA1通道1,在半传输中断和完全传输中断里,拷贝ADC采集的数据。在应用过程中发现DMA半传输中断和完全传输中断不能独立使用。

具体体现:
1、在DMA1初始化时,打开了半传输中断,关闭完全传输中断,照样能触发完全传输中断
LL_DMA_EnableIT_HT(DMA1,LL_DMA_CHANNEL_1);//打开DMA1半传输中断
LL_DMA_DisableIT_TC(DMA1,LL_DMA_CHANNEL_1);//关闭DMA1完全传输中断 
2、在DMA1初始化时,关闭了半传输中断,打开完全传输中断,照样能触发半传输中断
LL_DMA_EnableIT_TC(DMA1,LL_DMA_CHANNEL_1);//打开DMA1完全传输中断
LL_DMA_DisableIT_HC(DMA1,LL_DMA_CHANNEL_1);//关闭DMA1半传输中断

这个问题很让他很困惑,想知道怎么回事。

关于这个问题,我们在操作DMA相关的使能位或做相关传输长度配置时,一定要注意他们往往要求在DMA通道未被使能的前提下进行【具体阅读芯片手册】。现在的问题是,他想对DMA传输中断使能位进行改写,依然也有这个前提。见下图黄色高亮内容,即当相应DMA通道被使能时,是不接受对相应DMA通道的传输完成和半完成中断使能的改写。

STM32

换言之,这里若要对相应中断使能位进行改写,得先将DMA通道使能位【EN位】进行清零。使用LL库的话就调用LL_DMA_DisableChannel()函数实现, 修改相应中断使能位之后再将DMA通道打开,即调用LL_DMA_EnableChannel()函数。

STM32

问题2、用户使用STM32G431芯片,用到TIMER1的PWM功能,并启用基于TIMER事件的DMA Burst传输实现4个比较通道寄存器的批量修改。使用CubeMx进行配置。配置时发现一点疑惑,为什么外设端不需地址自增的勾选。

STM32

现在用户的具体情况就是利用TIMER更新事件触发DMA请求,每次更新事件触发DMA将4个内存数据转发给定时器的4个CCR寄存器。

STM32

按照客户的理解,在做DMA配置时这里的外设地址也应该勾选自增才对,可事实发现不勾选才结果正常,若选择外设地址自增了反而异常。

STM32

STM32

ST公司设计人员为了满足DMA对TIMER寄存器批量访问,还特别设计了2个寄存器,分别是TIMx_DCR和TIMx_DMAR。其中,DCR寄存器由DBL和DBA字段组成。

DBA:被访问的第一个定时器寄存器相对于定时器地址映射表中的TIMx_CR1的地址偏移量【偏移量从0开始计算】。

DBL:每组批量访问的寄存器个数【从0开始计算】。DMA访问DMAR寄存器时,按照如下算式得到绝对地址实现对寄存器的逐个访问。(TIM2_CR1address) + (DBA + DMA index)x 4 。

对于定时器DMA BURST传输,外设地址就是TIM2_DMAR寄存器的地址。DMA根据上面地址算式实现对多个TIMER寄存器的访问。TIM2_DMAR寄存器地址本身是固定的,无须增减,所以基于定时器事件DMA Burst模式配置外设时不要做地址自增勾选。

当然,上面需求也可以基于非Burst模式来完成。假设还是基于4个内存数据修改4个CCR寄存器,此时则需要4次定时器事件触发DMA请求,做DMA配置时需要将内存端和外设端都选择地址自增模式。基于CubeMx的参考配置如下:

STM32

当然,相应API函数也跟Burst模式下的也不一样【这里依然使用更新事件申请DMA】。 HAL_DMA_Start_IT(&hdma_tim1_up,(uint32_t)T1_CCRData, (uint32_t)&htim1.Instance->CCR1,4); 下面是两种不同访问模式下的示意图,图示可能更直观些。

STM32

好,今天的分享就到这里,下次再聊。

  审核编辑:汤梓红

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分