有人使用STM32F446做產(chǎn)品開(kāi)發(fā)，用到TIM1的4個(gè)通道做PWM輸出。具體使用是這樣的，選擇CHI1采樣PMW模式做PMW輸出。CH2、CH3、CH4采用比較切換模式結(jié)合DMA輸出PWM波形,其中各通道的CCR值通過(guò)DMA基于比較事件周期性循環(huán)修改。

客戶(hù)使用CubeMx做圖形化配置后生成基于HAL庫(kù)的工程，然后添加相關(guān)用戶(hù)代碼。

組織完用戶(hù)代碼后，不論代碼順序如何調(diào)整，發(fā)現(xiàn)總是最多只能啟動(dòng)2路使用OC切換模式結(jié)合DMA實(shí)現(xiàn)PWM輸出的通道。

DMA緩沖區(qū)配置：

uint32_t? ? ?tim_CCR2_Data[] = {8*9, 20*9};

uint32_t? ??tim_CCR3_Data[] = {10*9, 20*9};?

uint32_t? ??tim_CCR4_Data[] = {17*9, 20*9};

如果按照上圖組織代碼，代碼運(yùn)行到箭頭處就不往下走了，通道4無(wú)輸出。

如果說(shuō)代碼按照上圖組織編寫(xiě)，不僅通道4沒(méi)輸出，連通道1都沒(méi)有輸出。也就是說(shuō)運(yùn)行到綠色箭頭所指后程序就運(yùn)行不下去了，至少調(diào)試時(shí)短時(shí)間感覺(jué)上是這樣。

像這種問(wèn)題，我懷疑過(guò)是否跟HAL庫(kù)函數(shù)里有些狀態(tài)機(jī)變量的處理有關(guān)，但從現(xiàn)象來(lái)看又不像，因?yàn)檫@里有2個(gè)HAL_OC_Start_DMA()函數(shù)可以正常運(yùn)行?，F(xiàn)在癥狀是代碼沒(méi)法正?；蛘邲](méi)法順暢地運(yùn)行下去，感覺(jué)CPU太忙或跑飛了。

先不管它，自己參照客戶(hù)的功能需求找塊F446的板驗(yàn)證下。我測(cè)試了相同功能，結(jié)果并未遇到客戶(hù)反饋的問(wèn)題。我的用戶(hù)代碼跟客戶(hù)的是一樣的，就重點(diǎn)比較我與客戶(hù)的有關(guān)TIMER的時(shí)間參數(shù)。結(jié)果發(fā)現(xiàn)我設(shè)置的時(shí)間參數(shù)跟客戶(hù)設(shè)置的差別比較大，客戶(hù)設(shè)置的TIM1的溢出周期遠(yuǎn)小于我的?？吹竭@里我就基本鎖定原因了。我把TIMER時(shí)間參數(shù)改得跟客戶(hù)一樣后，進(jìn)行測(cè)試。

經(jīng)過(guò)測(cè)試立即呈現(xiàn)客戶(hù)反饋的問(wèn)題。

TIMER計(jì)數(shù)溢出時(shí)間參數(shù)改小了為什么就出現(xiàn)程序不能完整【至少短時(shí)間內(nèi)】運(yùn)行呢？

這里使用CubeMx進(jìn)行配置并采用HAL庫(kù)編程，當(dāng)使用OC 切換輸出并結(jié)合DMA傳輸功能時(shí)，同時(shí)也默認(rèn)開(kāi)啟了DMA傳輸?shù)耐瓿芍袛嗪桶胪瓿芍袛?。具體到這里，每個(gè)DMA通道只做2個(gè)數(shù)據(jù)的循環(huán)傳輸，因半完成和完成中斷都開(kāi)啟了，意味著每傳輸1個(gè)數(shù)據(jù)就發(fā)生1次中斷，每個(gè)計(jì)數(shù)周期將發(fā)生2次中斷，分別是半完成中斷和完成中斷。顯然，當(dāng)TIMER的溢出周期設(shè)置得越小，發(fā)生中斷的頻率就越高。另外，每增加1個(gè)通道的DMA傳輸，意味著每個(gè)計(jì)數(shù)周期內(nèi)又增加2次中斷。

顯然，隨著開(kāi)啟的OC切換通道的增加，DMA中斷就相應(yīng)增多；另外，隨著TIMER計(jì)數(shù)溢出頻率的提升，DMA中斷響應(yīng)就變得更頻繁。到達(dá)一定程度時(shí)就會(huì)導(dǎo)致CPU根本沒(méi)法再往下運(yùn)行主流程代碼，而被頻繁的DMA中斷死死地纏住。?相反，當(dāng)TIMER的計(jì)數(shù)溢出頻率放慢下來(lái)時(shí)，CPU即使依然要頻繁響應(yīng)各個(gè)通道DMA中斷，但中斷響應(yīng)頻率降下來(lái)了，此時(shí)依然有可能有空閑去繼續(xù)運(yùn)行主流程代碼，而不至于卡死【或近似卡死】在哪個(gè)位置。顯然，計(jì)數(shù)溢出頻率越低，就相對(duì)越不容易出現(xiàn)程序執(zhí)行卡死的狀況。

事實(shí)上，當(dāng)發(fā)生主程序代碼運(yùn)行不下去時(shí)我們暫停程序運(yùn)行時(shí)可以非常清晰地看到程序指針都落在DMA中斷服務(wù)程序的某行代碼上?！具@里也可以判斷程序并非跑飛】

到此，原因搞清楚了，即開(kāi)啟基于DMA傳輸?shù)?路OC輸出后，當(dāng)定時(shí)器的溢出頻率到達(dá)一定程度時(shí)，CPU忙于應(yīng)付頻繁的DMA傳輸中斷，難以抽身或完全抽不開(kāi)身繼續(xù)運(yùn)行主程序代碼了。那么，如何解決呢？

在不影響功能需求的情況下，適當(dāng)放慢TIMER的計(jì)數(shù)溢出頻率的確也是個(gè)辦法。不過(guò)，我們必須清楚，在這種情況下總的DMA中斷還是很多的，對(duì)CPU資源的耗用較大，必要時(shí)可以考慮下面的辦法。

具體到這里，有3個(gè)通道使用DMA傳輸，DMA無(wú)非就是周期性修改CCR值來(lái)實(shí)現(xiàn)特定的波形輸出。對(duì)于開(kāi)啟DMA傳輸?shù)陌胪瓿芍袛嗪屯瓿芍袛嗟谋匾圆淮?，完全可以關(guān)掉二者。其實(shí)，哪怕只關(guān)閉半完成中斷也讓CPU負(fù)荷大大減少。至于關(guān)閉DMA的相關(guān)中斷使能及響應(yīng)，我們可以手動(dòng)調(diào)整代碼，也可以在進(jìn)行CubeMx配置時(shí)直接關(guān)閉其中斷響應(yīng)。有些人可能不了解在CubeMx圖形界面下的操作，這里稍作演示。詳見(jiàn)下圖，先把Force DMA Channel Interrupt復(fù)選框取消，然后在DMA中斷使能復(fù)選框也取消使能，最后變成類(lèi)似下圖的樣子。

關(guān)于這個(gè)主程序代碼無(wú)法正常運(yùn)行下去的問(wèn)題，到底是TIMER原因還是DMA原因呢？應(yīng)該說(shuō)問(wèn)題跟二者密切相關(guān)，問(wèn)題的解決離不開(kāi)對(duì)相關(guān)知識(shí)點(diǎn)的細(xì)致了解。不過(guò)，個(gè)人認(rèn)為本質(zhì)上講屬于中斷方面的問(wèn)題。這里順便提醒下，我們?cè)谑褂肅ubeMx進(jìn)行配置時(shí)，涉及DMA的中斷響應(yīng)的配置都是默認(rèn)開(kāi)啟了的。另外，使用HAL庫(kù)的API代碼啟動(dòng)DMA時(shí)默認(rèn)也開(kāi)啟了DMA相關(guān)中斷使能。或許像上面提到的API代碼?HAL_TIM_OC_Start_DMA(）表面上看不出開(kāi)啟DMA中斷的痕跡或提示，但點(diǎn)開(kāi)進(jìn)去閱讀就會(huì)有所發(fā)現(xiàn)。

編輯：黃飛

?