某STM32用戶反映，他目前使用STM32F407VE的芯片開發(fā)產(chǎn)品，在使用CubeMx做初始化配置時發(fā)現(xiàn)沒法給UART5配置基于該外設(shè)事件的DMA請求。他覺得很奇怪,堅信UART5是可以申請DMA傳輸?shù)模宜€基于早期CubeMx 版本配置過、使用過。

他剛好最近對CubeMx升級到5.5.0了，懷疑是不是STM32CubeMx5.5以上版本的bug。

說到這里，可能有人還不是沒完全明白具體怎么回事。我們結(jié)合他給過來得截圖一起來看看。他在對uart5做配置時出現(xiàn)的界面是下面這樣的，連那個DMA配置的菜單都沒有。

基于他的反饋，我用目前最新的CubeMX版本5.6.1進行驗證，同樣對STM32F407VE的UART5進行配置并試著為其申請DMA傳輸。經(jīng)過測試并沒有碰到他所說的問題。

那問題出在哪兒呢？

我的測試工程只是單純使用到UART5，并未使用其它外設(shè)及相關(guān)DMA應用。我結(jié)合他反饋過來的配置截圖，隱約發(fā)現(xiàn)他的工程應用中并不僅僅使用一個UART5外設(shè)，還用到了其它外設(shè)。會不會是他在配置其它外設(shè)并申請DMA請求時，把UART5可以申請的DMA流占用了呢？

我們先不妨打開STM32F4系列參考手冊的DMA章節(jié)，看看有關(guān)外設(shè)事件與DMA傳輸流的映射關(guān)系圖。從手冊中我們可以看到，UART5的TX/RX事件能申請DMA毫無疑問，但只能申請DMA1_S0和DMA1_S7。

然而呢，可以申請DMA1_S0和DMA1_S7的外設(shè)事件又有很多，比方TIM4_CH1和TIM4_CH3就可以分別申請DMA1_S0和DMA1_S7。如果說，在做UART5事件的DMA配置之前，若有別的外設(shè)事件已經(jīng)將DMA1_S0和DMA1_S7申請走了，這時UART5就應該沒得申請了。

基于上面分析，我們可以進一步驗證下。

我們使用上面提到得TIM4_CH1和TIM4_CH3先將DMA1_S0和DMA1_S7申請走，再來嘗試為UART5申請DMA，看看會怎么樣。結(jié)果CubeMX提示該外設(shè)請求無效，不能申請DMA了。如下圖所示：

提示界面跟客戶反饋的不太一樣，應該是CubeMx版本的差異所致。表達的基本意思還是相同的，即此時沒法為UART5事件申請DMA傳輸。

到此，客戶反饋的問題原因也基本清晰。像這種情況，由于UART5的TX/RX事件要申請的DMA流固定了，我們可以看看目前占用uart5欲申請的DMA流的外設(shè)，他們是否可以做調(diào)整去申請別的DAM流，從而避免競爭。因為有些外設(shè)事件可能申請的DMA流不只一條，當然這要結(jié)合具體的芯片。以STM32F4芯片為例，下圖中的TIM1_CH1,SPI1_RX，SPI1_TX可申請的DMA傳輸流都不只一條。

或許有人知道，STM32家族中有些系列支持DMAMUX，如果有它做DMA配置就更方便、高效。但不管怎樣，DMA請求事件肯定要遠遠多于具體實施傳輸?shù)腄MA流，所以具體應用中并不能保證有申請DMA資格的事件就一定申請得到相應的DMA傳輸。就像你有錢也有資格坐飛機坐高鐵，但并不能保證你時刻可以買到你期望的機票或火車票而成行。

再結(jié)合到本案例，遇到兩個外設(shè)事件對一個DMA傳輸流發(fā)生競爭不可避免的時候，若兩個外設(shè)對DMA的使用在時間上可以錯開的話，也還是有辦法解決的。我們可以使用CubeMx分別基于兩個外設(shè)的DMA請求事件生成兩套配置，然后手動調(diào)整代碼，需要使用哪個外設(shè)事件的DMA傳輸時就啟用相應的DMA配置及應用函數(shù)?？傊?，搞清了怎么回事，結(jié)合具體應用靈活處理就好。

最后小結(jié)下。針對上面的客戶問題，如果對CubeMx工具的使用不熟或者說只是機械地使用該工具做配置，心里沒有些基本原理做支撐的話，遇到該問題時恐怕一時也的確難以找到方向。在此分享，權(quán)作提醒。