某STM32用戶開發(fā)產(chǎn)品，用到ADC模塊，通過定時(shí)器更新事件觸發(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)用代碼對(duì)該標(biāo)志進(jìn)行監(jiān)視。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于調(diào)整過的代碼進(jìn)行測(cè)試，還真發(fā)現(xiàn)了一使能第二次DMA傳輸時(shí)就先傳一個(gè)數(shù)據(jù)的現(xiàn)象。可是此時(shí)定時(shí)器仍未啟動(dòng)，DMA怎么就開始傳輸數(shù)據(jù)了呢。【結(jié)果如下圖所示】

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

我們不妨先理一理：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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