STM32F0 ADC结果挪位的问题分析及解决

有人利用STM32F030芯片内置的ADC模块，使用了CH0、CH3、CH5这三个通道进行单次扫描转换，并通过DMA将结果存放在一个数组中。ADC的扫描方向被设置为Forward，即按照通道编号从小到大的顺序进行转换。

在ADC的DMA传输完成中断中，试图改变选择的通道序列，将原来的CH0、CH3、CH5改为CH1、CH3、CH5后，出现了不同通道数据位置错乱或错位的情况。正常情况下，转换结果应该在20以内，但出现了大约1480的数值。

为何会出现这种情况？是否一旦选定了转换序列，就无法再改变？

简单来说，上述情况表明在更改ADC通道并形成新的转换序列后，转换结果与预期不符，出现了异常情况。

针对这种情况，我选择了STM32F070RB开发板进行验证测试，使用了相同的3个通道进行验证。具体是对CH14、CH15和CH17进行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复用功能配置好。

好，今天的话题就聊到这里。下次再聊。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！