1
有人使用STM32F030芯片内部ADC的CH0、CH3、CH5共3个通道,单次扫描转换后通过DMA将结果放在一个数组,。ADC转换多通道的扫描方向是Forward,即将所选择通道按照从小编号往大编号通道依次转换。
在ADC的DMA传输完成中断里改变选择的通道序列,将原来的CH0、CH3、CH5改成CH1、CH3、CH5后,出现不同通道数据窜位或挪位情况。正常转换后的值应在20以内,却出现了1480左右的数值。
为什么会出现这种情况?是不是选定了一个转换序列后就不可以再改变转换序列?
简单点说,上面要表达的就是当更换ADC通道形成新的转换序列后,转换结果与预期不符,出现异常。
基于上面情况,我找到STM32F070RB 开发板做验证测试,尝试找找原因。也选用3个通道来验证。我这里先对CH14、CH15和CH17【内部与Vrefint电压相连】做ADC,其中CH14接地,CH15接VDD。转换结果使用DMA搬运到内存数组。
当上一个序列转换完成后,我将转换序列改成CH13,CH15,CH17,即将前面的CH14换成CH13,该通道未外接特定信号,处于浮空状态【转换结果可能不定】。然后,开启第2轮转换,之后结束测试。
我刚开始的用户测试代码是下面的这些。数组pData1[]和pData2[]分别存放前后两次的转换结果。用Delay(20)延时代替等待转换完成,反正这里只是做下验证测试而已。
两次的转换结果如下面截图所示:
第一次的3个通道的转换结果符合预期,是正确的。见上图中数组pData1【】的结果。
CH14接地,CH15接VDD,CH17接1.2v的Vrefint电压信号。
但第二次的3个通道的转换结果跟预期就不一致了。我希望得到的是CH13、CH15和CH17的转换结果,可现在看到的结果显然依次是CH13、CH14和CH15的,不见CH17的结果。
数据跟期望的不符,在内存中的位置也不对,出现了位置移动。另外,按理说CH14不应有转换结果出来,它明显出结果了。
难道说,我的第二次转换序列设置跟实际的转换序列不一致?现在感觉没看到CH17的结果,会不会已经出来了,只是跟我的DMA传输长度及数组长度设置有关?目前设置的长度为3,如果我把数组长度改长点,比方5吧。看看结果如何?
不出所料,看来第二次ADC转换的果真是4个通道的。见下图的pData2的结果。
这进一步证实了第二次的ADC配置有问题!再回头看看第2次ADC初始化的代码:
从代码上看似乎并没有啥问题。相比第一次配置,只是把CH14换成了CH13,难道说我的第2次ADC配置增加CH13的同时CH14并没有被替换掉,而是依然存在于新的转换序列?
我们不妨借助调试工具看看ADC通道选择寄存器内容来证实当前的猜测。运行程序后借助调试环境可看到下面的ADC通道选择器的结果。
的确,第2次ADC配置后,转换序列里是4个通道而不是3个通道,即CH14通道依然存在于转换序列。这跟当前的输出结果就非常吻合了,只是不符合当前需求而已。
那么,如何让第二次ADC转换只使用CH13,CH15,CH17三个通道呢?
我们可以这样操作,在做第2次ADC转换序列初始化前,先将ADC做下复位。将前面代码稍加改动,注意下面红色代码行。
再做调试运行,这次结果就正确了。见下面截图:
看来,问题出在ADC的配置方面,ADC转换序列当然可以修改,只是要按照正确的步骤操作才行。
顺便提下,CH13是代码里另外加进去的,使用CubeMx配置的话,记得将CH13的复用管脚事先配置成Analog模式,这样让CubeMx创建工程时自动帮我们将该脚的GPIO复用功能配置好。
审核编辑:刘清
全部0条评论
快来发表一下你的评论吧 !