某STM32用戶開發(fā)產(chǎn)品，用到ADC模塊，通過定時器更新事件觸發(fā)AD轉(zhuǎn)換，轉(zhuǎn)換結(jié)果由DMA搬運(yùn)到指定的內(nèi)存區(qū)域。DMA工作在正常模式（即非循環(huán)模式），每當(dāng)傳輸完畢一批數(shù)據(jù)后在傳輸完成中斷里設(shè)置傳輸結(jié)束標(biāo)志,應(yīng)用代碼對該標(biāo)志進(jìn)行監(jiān)視。

當(dāng)檢查到該有效標(biāo)志時，說明采集到了預(yù)定的轉(zhuǎn)換數(shù)據(jù)。將數(shù)據(jù)處理后，軟件產(chǎn)生TIMER更新事件,以保證計數(shù)器從0開始計數(shù)【注：這里選用的向上計數(shù)模式】。然后清除更新事件標(biāo)志、ADC轉(zhuǎn)換完成標(biāo)志位EOC ，關(guān)閉DMA后對DMA進(jìn)行再配置，然后重新使能DMA進(jìn)行第二次傳輸。

調(diào)試中發(fā)現(xiàn)，對于第二次DMA傳輸，每次一使能DMA 就立即搬運(yùn)一個數(shù)據(jù)。按理說應(yīng)該延時一個定時器更新周期后才會搬運(yùn)首次數(shù)據(jù)才對。因為軟件置位UG位后，用來觸發(fā)ADC的TIMer是從0開始計數(shù)的，需要計數(shù)到溢出才會觸發(fā)AD轉(zhuǎn)換。他想不明白的是TIM已經(jīng)復(fù)位從0開始計數(shù)了，該清的標(biāo)志位都清除了，還有什么原因?qū)е翫MA不等TIMER觸發(fā)就立即先行搬運(yùn)一個數(shù)據(jù)呢。

該問題源于某STM32論壇，但用戶沒有貼出任何代碼。這里模擬他的應(yīng)用場景做個測試驗證，并試圖找出相關(guān)原因。

我這里也設(shè)計了兩輪DMA傳輸，照樣使用TIMER更新事件觸發(fā)ADC轉(zhuǎn)換。第一輪DMA傳輸傳輸3個AD轉(zhuǎn)換結(jié)果到某內(nèi)存地址，第二輪傳輸5個轉(zhuǎn)換結(jié)果到另一內(nèi)存位置。

先使用Stm32CubeMx基于STM32F411Discovery板進(jìn)行基本的初始化配置。配置都很簡單。

ADC配置，這里只選擇1個常規(guī)通道用于測試，選擇TIM2的觸發(fā)輸出啟動AD轉(zhuǎn)換，并開啟ADC的DMA傳輸功能，DMA工作在Normal模式?！居布螦DC輸入通道我直接連VDD了】

TIMER配置，這里選擇TIM2，其更新事件做為觸發(fā)輸出用來啟動ADC。

配置完畢后生成初始化代碼，然后添加用戶代碼。

這里準(zhǔn)備了幾個內(nèi)存變量.

我在第一次DMA傳輸完成后立即關(guān)閉定時器，在開啟第二輪DMA傳輸前，不讓定時器有機(jī)會再次觸發(fā)ADC產(chǎn)生EOC事件?？纯从袩o他說到的情形發(fā)生。

我把用戶代碼分成兩部分，分別用紅框、綠框區(qū)分。

第一部分由基本的初始化函數(shù)、開啟ADC外設(shè)及其DMA功能、對第一次DMA傳輸做配置并使能DMA、等待3次ADC轉(zhuǎn)換結(jié)束。

第二部分代碼的功能主要關(guān)閉定時器、關(guān)閉DMA,第二次對DMA進(jìn)行配置，再開啟DMA功能并啟動定時器?！疚野褦帱c(diǎn)打在箭頭所指的地方，即待啟動計數(shù)器的那句代碼處】

基于上述代碼測試，沒有發(fā)現(xiàn)一使能第二次DMA傳輸就先傳一個數(shù)據(jù)的現(xiàn)象。這時定時器也沒被啟動，DMA處于就緒待命狀態(tài)?！窘Y(jié)果如下圖】

那客戶反饋的情況到底是怎么回事呢？

因為沒見到用戶具體的代碼，他說過在DMA做完第一次傳輸后，還對定時器做了復(fù)位。那我們不妨在第一次DMA傳輸結(jié)束后，增加對定時器的復(fù)位操作，看看結(jié)果會怎么樣。

我將第二部分代碼稍作修改如下【見下圖中A處代碼】:

基于調(diào)整過的代碼進(jìn)行測試，還真發(fā)現(xiàn)了一使能第二次DMA傳輸時就先傳一個數(shù)據(jù)的現(xiàn)象?？墒谴藭r定時器仍未啟動，DMA怎么就開始傳輸數(shù)據(jù)了呢?！窘Y(jié)果如下圖所示】

當(dāng)然，單純從DMA傳輸功能來講，它跟定時器是否啟動并沒有必然聯(lián)系。對于被使能了的DMA，只要有合適的DMA請求出現(xiàn)，它就行使職能。具體到這里，應(yīng)該是有EOC事件出現(xiàn)了才會發(fā)生DMA傳輸?shù)摹Ｄ沁@個EOC事件從哪里來的呢？

我們不妨先理一理：

第一次DMA傳輸完成后不可能還有待處理EOC事件存在。在第一次DMA傳輸過程中，每次DMA讀取ADC數(shù)據(jù)就保證EOC被清零了，DMA傳輸完成后又立即關(guān)閉了定時器，本案例里也沒有別的事情影響定時器的迅速關(guān)閉。按理說在兩次DMA傳輸之間不會有定時器更新事件觸發(fā)AD轉(zhuǎn)換，更何況在使能第二次DMA前還專門做了EOC的清除操作。

看起來的確有點(diǎn)奇怪，怎么感覺有個DMA請求，用客戶的話說，好像潛伏在哪里一樣？

目前的代碼跟剛開始的比，多了個定時器的復(fù)位操作。難道這個復(fù)位操作會導(dǎo)致ADC轉(zhuǎn)換而生成EOC事件？說到這，它還真有這本事。

因為軟件方式對定時器進(jìn)行復(fù)位也可以產(chǎn)生更新事件，它正好能啟動AD轉(zhuǎn)換【AD轉(zhuǎn)換功能一直都沒關(guān)閉過】從而產(chǎn)生EOC事件。如果EOC標(biāo)志沒有及時清除的話，就可以在下次DMA傳輸剛被使能，即使計數(shù)器還沒被啟動的條件下觸發(fā)一次DMA傳輸。

分析到這里，感覺找到問題原因了。但是，似乎還是有點(diǎn)不對勁。因為即使定時器復(fù)位動作產(chǎn)生更新事件而觸發(fā)ADC轉(zhuǎn)換，進(jìn)而產(chǎn)生EOC事件， 但我們在定時器復(fù)位動作之后還特意做過對EOC標(biāo)志的清除?！鞠聢D中的第二個紅圈內(nèi)的代碼】

難道說這個清除EOC標(biāo)志的操作有問題？

先確認(rèn)代碼寫法本身，沒有問題。再看邏輯和時序上問題。

通過進(jìn)一步的調(diào)試，在下圖所示代碼處放了3個斷點(diǎn)單步運(yùn)行，的確發(fā)現(xiàn)定時器復(fù)位事件觸發(fā)了ADC轉(zhuǎn)換，EOC被置位。在后續(xù)代碼中也發(fā)現(xiàn)EOC被清零了。有意思的是，當(dāng)開著下圖所示3個斷點(diǎn)來運(yùn)行時，那個奇怪的現(xiàn)象就消失了，那潛伏的DMA請求似乎遁形了。

如果取消上面的第1、第2個斷點(diǎn)后運(yùn)行代碼，那個現(xiàn)象立即又重現(xiàn)，潛伏的又激活了。

反復(fù)驗證到這里，基本上明白是怎么回事了。

毫無疑問，定時器的復(fù)位操作導(dǎo)致AD轉(zhuǎn)換而產(chǎn)生了EOC事件。代碼里雖然有對EOC的清除操作，但該操作相對ADC而言，太早了點(diǎn)。即在針對EOC做刪除操作時，ADC可能還在忙著轉(zhuǎn)換，離產(chǎn)生EOC事件還早呢。這正好可以解釋為什么在復(fù)位操作代碼后放個斷點(diǎn)再刪除EOC就有效的情形。

既然這樣，我在清除EOC操作代碼的前面加一句EOC標(biāo)志查詢等待，以保證后續(xù)的清除操作可靠有效。我將代碼再次做了調(diào)整。見下圖中方框內(nèi)代碼。

就修改過的代碼進(jìn)行驗證，那個現(xiàn)象徹底消失。后續(xù)的第二輪DMA傳輸也規(guī)規(guī)矩矩了。

到此，本應(yīng)用案例分享結(jié)束。最后，稍作小結(jié)并做些提醒：

1、針對STM32定時器的軟件復(fù)位操作可以產(chǎn)生更新事件，其效果等同于定時器溢出導(dǎo)致的更新事件。

2、我們編寫代碼，尤其這種嵌入式代碼時，除了保證代碼基本的正常邏輯外，各個硬件本身操作時序、響應(yīng)時間參數(shù)等也須多加關(guān)注。

3、結(jié)合本案例，在第一次DMA傳輸完成后為第二次DMA做準(zhǔn)備時，建議先關(guān)閉計數(shù)器，否則可能會給我們的應(yīng)用帶來些隱患，本案例中探討的問題，就是其中隱患之一。限于篇幅和主題，這里就不啰嗦了，后面若有合適案例再行交流。