有人想使用STM32U5系列的GPDMA的burst【分組、節拍、突發】傳輸功能，似乎遇到了點阻礙。我這里嘗試下，稍作演示，僅供參考。

我用TIMER1更新事件觸發DMA， DMA工作在非循環模式，DMA將數據從源內存區傳輸到目的內存區。我先準備下面兩個數組。

當兩端訪問數據寬度設置一樣，burst大小始終為1時，傳輸是很順暢的，不會有啥問題，結果符合預期。

基于上面配置，結果就很正常。結果如下圖，也正是我期望的結果。

當我們嘗試使用DMAburst功能時，發現結果就不對勁了，比方我希望源端按字節讀取，然后基于BURST功能打包，目的端按半字來提取，發現結果跟預期不一樣。我們一起看看：

顯然，每半個字的高字節都是填充的0。那是怎么回事呢？

我們再看看源端按字節讀取，然后基于BURST功能打包，目的端按字來提取，看看結果又會怎么樣？

結果變成了上面的那個樣子，顯然結果嚴重不符合預期。

那是怎么回事呢？ 經過反復修改參數，結合我之前之前玩過F4系列DMA burst傳輸功能以及對STM32 DMA burst功能的理解，感覺這里的BUSRT傳輸應該是工作了。對DMA burst的基本配置以及我的用戶實現代碼還是比較自信的。而且目前結果上來看，有數據傳輸，且數據結果是有規律的，數據并不混亂，程序也沒跑飛，就是感覺數據好像在DMABURST傳輸過程中被處理過。

剛好這兩天也就隨機性瞄了下這塊，隱約記得它是有數據處理功能的。【說實話，U5系列DMA好復雜，比其它M4核STM32的DMA復雜很多。要沉下心來細看真不易！！】

想到這里，不禁自我懷疑。難道配置哪里還有問題，沒做到位？

繼續查看CubeMx界面下有關GPDMA的配置，嗯？我看到了一直被我無視的一個地方：

難道問題是在這里？此處有乾坤？

。。。。。。其實，問題真的就在這里。

當我將那個DataHandling 配置由Disable轉為Enable基本恍然大悟了。

我們回過頭去查看手冊，手冊里面對GPDMA的數據處理功能也做了描述。下圖是相關描述里的一個表格截圖。

關于GPDMA的數據處理功能，這里就不解讀了，需要時我們可以自行研讀手冊。對STM32U5的DMA功能，我只能說：哇塞！功能真強大！

我們還是繼續回到上面的測試。當我使能Datahandling功能，并選中滿足我當前需求的一個選項后，一切便撥云見日。

注意上面截圖中那個關于數據對齊的選項。意思還是比較簡單明了，當源數據寬度小于目的端數據寬度時，按照目的端數據寬度打包擺放。

當我在前面BURST配置的前提下，再加上這個Data Handling配置就能輸出符合預期的結果了。

換句話說，我前面的DMA Burst基本配置是沒有問題的，只是沒有選擇合適的Data Handling方式導致沒有呈現我們預期的效果，這也正是它跟其它系列不一樣的地方。

這里涉及的用戶代碼很簡單，也干脆貼過來，供有需要的參考【初始化配置使用CubeMx】：

最后順便提醒一點，上面那個DMA啟動函數里的size變量【箭頭所指的地方】，是按照字節數來算的，這點要注意，這也是跟其它系列不一樣的地方。

審核編輯 ：李倩