有人使用STM32H7系列芯片，用到UART做字符串輸出時遇到點小問題。這里一起聊聊該問題，并分析問題原因。【注：下面所用IDE乃ARM keil MDK】

事情是這樣的，他基于DMA方式通過UART對外發送“Hello”字符串，可無意中發現當該字符串以不同的變量形式提供給函數時結果卻不一樣。不妨以下面示意的功能代碼為例來看。

上圖中的主要功能就是基于DMA方式通過UART發送兩次字符串，一個字符串是“Hello,STM32-1!”，另一個是“Hello,STM32-2!”，兩字符串一字之差以示區別，便于調試。

可是，按照上面寫法和默認編譯條件，測試發現只有第一個UART發送函數有效，第二個UART發送函數沒有相應輸出。見下面輸出截圖：

那是為什么呢？兩個函數的實現及變量幾乎一模一樣。如果不使用DMA方式做UART發送會怎么樣呢？即將UART的發送改成查詢方式的API函數，見下面截圖：

結果發現，如果按照上面的寫法，兩行功能代碼的輸出又是正常的，見下面輸出結果截圖。

看來，問題的出現跟使用DMA有關。既然問題跟DMA有關，為什么同樣使用基于DMA方式的UART發送函數，一行可以另一行卻無效呢？這兩行的唯一差別就是在提供發送字符串的形式上的差異。一行是基于字符串常量提供給函數，一行是基于內存變量提供給函數。

現在的情況是，基于字符串常量提供給函數的可行，基于內存變量提供給函數的不可行。

這就可能涉及到DMA訪問地址空間的可行性問題，一般來講，每個DMA往往有其可訪問的地址范圍問題，并非無所不達。具體到STM32H7系列，其通用DMA是沒法訪問TCM區域的。當然，對于內核CUP而言，它自然沒有訪問不到的地址空間問題，所以剛才基于查詢式做發送時兩行函數功能都正常。

具體到這里，第一個字符串以常量形式提供給UART發送函數時，DMA可以訪問到，第二個字符串以內存變量形式提供給UART發送函數時，DMA則訪問不到。我們可以知道，字符串以常量形式提供給UART發送函數時，字符串是存放在FLASH里的。我們可以借助調試工具找到此時第一個字符串的具體存放地址，顯然是片內Flash地址。見下圖：

在STM32H7系列里，通用DMA方式片內Flash是沒有問題的。所以解釋了第一行代碼輸出正常。

那么，當第二個字符串以內存變量形式提供給UART發送函數時，該字符串到底存放在哪里呢？其實，其地址如果沒有刻意通過用戶指定的話，是編譯器根據當前的編譯配置自動安排的。我們借助調試工具，不難看到第二個字符串變量【TX_Buffer】就是存放下面的地址,即0x20000008開始的一段地址空間：

結合STM32H7系列手冊相關地址布局說明，不難得知第二個字符串存放在DTCM區域，正是通用DMA訪問不到的地址空間。

既然知道了原因，解決起來就就簡單了。我們可以在代碼里直接將字符串存放地址指定到通用DMA可以訪問到的地方，比方AXIRAM,SRAM1/SRAM2/SRAM3任意區間。

我在下面使用AXI RAM作為默認的內存空間，也無須通過用戶代碼做地址的指定，只是稍微調整了ARM MDK IDE的鏈接配置選項，見下面示意圖。【注：不同的IDE，這個地方的操作會略有差異。】

然后基于之前的代碼重新編譯、運行，結果正常，不再有發不出去的Hello了。

DMA作為CPU的強力幫手,也有鞭長莫及的時候，我們在STM32應用中要加以留意。