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

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

組織完用戶代碼后，不論代碼順序如何調(diào)整，發(fā)現(xiàn)總是最多只能啟動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無輸出。

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

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

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

經(jīng)過測試立即呈現(xiàn)客戶反饋的問題。

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

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

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

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

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

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

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

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

編輯：黃飛

?