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

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

經(jīng)了解，客戶的確做了flash編程，有一部分參數(shù)需要存放在FLASH內(nèi)。他的ADC3是由TIM2觸發(fā)的，ADC3的轉(zhuǎn)換結(jié)果是通過DMA搬運。

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

客戶進一步反饋確認：

1：通ADC結(jié)果過DMA讀取，并非中斷方式獲??；

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

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

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

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

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

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

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

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

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

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