STM32F030芯片内部ADC结果挪位的问题分析及解决办法

有人使用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复用功能配置好。

审核编辑：刘清