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

審核編輯：劉清