某STM32用戶使用STM32F407芯片開發產品。用到內部3個ADC，其中ADC1與ADC2工作在ADC雙模式，ADC3獨立工作。運行代碼時給FLASH開鎖編程后，發現ADC3不工作了（其DR數據寄存器似乎不更新了，倒是用來觸發ADC的定時器TIM2依然正常），Flash編程前后ADC3配置寄存器CR1、CR2沒有發生改變。如果重新配置ADC3后就能正常工作。

從問題現象來看，初步感覺跟flash編程有些關系。

經了解，客戶的確做了flash編程，有一部分參數需要存放在FLASH內。他的ADC3是由TIM2觸發的，ADC3的轉換結果是通過DMA搬運。

鑒于此，我這邊便提醒他，如果不是基于雙BANK條件，在flash編程時CPU是堵塞的，此時若發生中斷不會得到響應,讓他注意這點及因此可能導致的問題。

客戶進一步反饋確認：

1：通ADC結果過DMA讀取，并非中斷方式獲取；

2：FLASH編程過程中禁止了所有中斷；

3：奇怪的是ADC3改為由軟件觸發則沒有異常現象。用來觸發ADC的定時器一直計數正常，并且只要重新配置ADC3（無須對觸發定時器重新配置）也能恢復它的正常工作。

先說下客戶提到的在flash編程時將總中斷關閉動作。其實，從效果來講，這個關中斷沒啥用，反正在Flash編程過程中即使有中斷發生CPU也不會給予響應。

結合其反饋，軟件觸發和定時器觸發ADC有個明顯差別，就在于定時器的觸發對于我們用戶來講往往存在些未知性或不確定性，即不知它具體的觸發時間點。客戶一直強調TIM工作保持正常，對ADC不能被觸發感到奇怪。

整體上，通過問題癥狀結合經驗初步判斷是ADC3發生溢出事件了，建議客戶做進一步檢查確認。

后來，他反饋的確是發生了ADC溢出事件。在FLASH編程前暫停TIM2觸發就可以避免溢出發生，不再發生ADC功能異常。

按理說他現在ADC結果是DMA傳輸，TIM觸發DMA時應該可以及時讀取數據的，怎么還發生了溢出呢？那就有種可能，在某個時刻，當ADC被TIM觸發完成轉換后，這時的DMA還沒有準備好，導致ADC的結果沒有被及時取走。

那什么原因會導致ADC結果不能被及時取走呢？若DMA配置在非循環模式，當DMA傳輸完成一輪數據后，DMA將不再繼續實施數據傳輸，這時CPU往往還會進入DMA中斷服務程序做些必要處理或者為下輪傳輸做準備。若這個DMA傳輸完成中斷發生在FLASH編程期間，這就可能導致問題。由于該期間它本身不能得到響應，下一輪的DMA傳輸就沒法被開啟。但此時的TIM還是依然如故地觸發ADC,其結果若不能被及時取走，導致溢出就再自然不過了。

當ADC發生溢出后，如果沒有對溢出位做清零，后續的ADC轉換動作是不會觸發DMA的。具體到本案例，嚴格地講，后來客戶覺得讀不到ADC的更新數據，不是因為ADC不工作，其實它一直被定時器觸發轉換，只是因為發生了溢出，沒法正常觸發DMA傳輸，進而無法實現ADC結果的搬運。

所以，在上述應用情況下，在做flash編程前可以先行關閉定時器，之后再打開。或者在DMA傳輸完成的中斷服務程序里，在重新開啟DMA之前，先暫時關閉定時器，對并ADC的溢出及出錯做檢測處理，之后再開啟定時器和DMA傳輸。