基于STM32F446的PWM輸出程序

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

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

組織完用戶代碼后，不論代碼順序如何調(diào)整，發(fā)現(xiàn)總是最多只能啟動2路使用OC切換模式結合DMA實現(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};

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

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

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

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

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

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

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

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

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

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

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

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

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

編輯：黃飛

?