?一、片內RAM用完了？

曾有兩個不同的STM32用戶反饋了相似的問題，他們在對STM32F7Cube庫里的工程例程進行編譯時，發現了一個令人很不解的事。編譯的結果提示芯片內的RAM幾乎都耗光了。但以他們對工程基本功能的了解，按理說不應該那樣，想知道是怎么回事。

具體情況是這樣的：他們先在STM32CubeF7的固件庫里打開了一個有關lwip應用的工程示例。比如下面目錄處的一個工程，使用ARM MDK進行編譯。

STM32Cube_FW_F7_V1.15.0ProjectsSTM32746G-DiscoveryApplicationsLwIPLwIP_HTTP_Server_Netconn_RTOSMDK-ARM。

結果發現編譯結果提示片內RAM的空間已經基本用完了。但感覺應該用不了那么多RAM內存。客戶還想添加自己的其它用戶程序，還需使用RAM呢。

打開相應軟件工程，使用ARM MDK進行編譯，發現編譯結果跟客戶反饋的一致。

從編譯結果來看，感覺RAM真的被用去了320多K，那RAM用到哪里去了呢？打開對應的MAP文件進一步查看，可得到如下數據。

先看看芯片內部RAM情況。目前使用的芯片是STM32F746NG，查看其數據手冊可知其內部系統RAM容量為320KB【1KB=1024B】,分別由如下三塊RAM區域組成，各區域容量及地址范圍如下：

結合編譯結果和上面數據信息來看，貌似RAM真的用完了。既然這樣，只好硬著頭皮繼續查看MAP文件的其它細節,?看看RAM到底消耗在哪些地方去了。后來發現在某個地址段有個巨大的PAD補丁填充區。

即從0x2000fd08到0x2004bfff這段區域，共246,520Bytes【即上圖?黃色區域所指】。

一般來講，代碼編譯后產生的PAD補丁塊往往是因為地址對齊方面的原因導致的一些不便使用的零散內存碎片，正常來講，?這些補丁塊不會大面積的集中在一起。

比如使用下面結構體變量的時候會插入padding.

?

但這里提示的補丁塊也太大了，高達200多KB而且是連續空間！感覺是哪里誤會了。從分析來看，初步判斷這個PAD區間應該還是可以被用戶使用的。于是嘗試在現有代碼里隨意增加一塊16KB的RAM有效使用量，編譯一切正常，編譯后顯示的內存用量結果跟之前幾乎一模一樣，依然顯示RAM用完了。

但通過查看MAP文件，可以發現上面提到的那個大補丁塊空間也隨之減小了16KB。顯然，RAM并非真正用完了，只是編譯器把它當作類似對齊原因導致的補丁塊了。現在問題是，怎么會被編譯器誤判成這么大的一個補丁塊呢？

進一步查看MAP和部分代碼源文件，我們可以發現有一塊RAM區域，即芯片內的SRAM2區域被用戶使用attribute關鍵字自行做了內存使用分配了，即這塊內存空間不是交給編譯器安排的。【下圖中綠色方框內的內存分配】

結合上面的分析，那個巨大的pad區域正是經編譯器分配使用到的RAM空間的?末尾地址開始?到SRAM2起始地址【0X2004C000】之前的那段空間。

這里讓人想到一個地方，那就是MDK IDE選項配置中Target配置的這個地方：

這里片內RAM配置是這樣的，意味著從0x20000000到0x2004ffff的全部RAM空間交由編譯器分配管理。

而在實際應用代碼中，編譯器從0x20000000開始分配內存，而SRAM2區域則由用戶自行安排使用的。這樣的話，經編譯器所分配所用到的RAM內存末尾到0x2004BFFF這段未用區域被視為了pad區域。看來只是誤會一場。

那如何消除這個誤會呢？我們可以將上面的內存配置項稍微修改下，讓SRAM2區域不再讓編譯器分配管理，這樣就避免了編譯器分配的內存末尾到SRAM2區域起始地址的這段空間被視為補丁區。像下面一樣修改：

這樣修改后再做編譯，結果如下，不再給人RAM都用光的感覺了，只用到70多KB的片內RAM。

??二、Flash編程算法用不了？

用人使用STM32F7開發產品，發現編譯時找不到合適的Flash算法文件，或者MDK自帶的現有FLM文件用不了。具體情況是這樣的：

有人使用STM32F750V8開發產品，編譯完畢后欲進行下載調試，結果沒法完成程序下載，提示FLASH下載錯誤。

檢查了各個配置后，懷疑FLASH算法文件是否有問題。

打開MDK選項配置里flash_download的編程配置頁面，那里已經添加了相關FLASH編程算法文件。

不過，如果使用STM32芯片做過開發的人可能比較容易發現有個地方有點刺眼，就是起始地址那個地方。用過STM32F0/F1/F4等系列的人可能比較容易發現，那個FLASH起始地址一般是在0x8000000這個地方，這里卻是0x00200000。我們再看看MDK選項配置有關內存分配的那個地方，如下圖所示：

這里的片內FLASH默認起始地址卻是0x8000000。顯然這里跟FLASH編程算法文件的起始地址定義不一致，初步判斷應該是這個地方導致的問題。

到此，我們有必要看看STM32F7的相關技術手冊了關于內部FLASH地址分配的內容。下圖是STM32F750片內主從外設及總線的框架圖，對于片內FLASH，CPU可以有兩條總線通路訪問它，一條是通過AXIM接口，經過AXI-AHB橋以64位總線訪問，另一條是通過ITCM接口，經過片內ART加速器后訪問它。【如下圖所示】

我們通過進一步查看手冊，可以得知CPU訪問該FLASH區域時因使用不同總線接口而安排了不同的地址訪問區域。

從上面表格可以清楚地看到，CPU從不同接口訪問FLASH時其對應地址是不一樣的。通過AXIM接口訪問內部flash的起始地址為0x08000000,通過ITCM接口訪問內部flash的起始地址是0x00200000.

結合到上面案例，MDK選項配置中Target頁面的片內FLASH地址安排與Flash算法定義的地址不一致導致程序下載失敗。那么,我們可以將二者的地址及大小調整得一致，具體根據實際開發需求來調整，即根據你希望CPU通過哪個接口來訪問FLASH來做相應調整。

1、如果希望走ITCM接口來訪問，我們就將Target頁面的FLASH存儲起始地址與FLASH算法文件定義的起始地址都設置為0x00200000，如下圖所示：

2、如果希望走AXIM接口來訪問，我們就將FLASH算法文件定義的起始地址與Target頁面定義得一致，這里就是0x08000000.

基于MDK提供的FLASH算法文件我們可以直接修改其起始地址及大小。

比如，如果剛加載進來的算法文件是基于ITCM接口的地址定義，如下圖所示。

我們可以直接基于上面算法文件參數進行起始地址修改，即修改橢圓里的起始地址數據，修改完畢后點擊下方的OK按鈕即可。操作如下圖所示：

【注：我所用ARM MDK版本為5.28。】

基于修改后的配置，再進行編譯后即可進行下載調試。