前言
有客戶用STM32F427芯片，程序將CSTACK放在CCM
RAM中，結果測試過一段時間的板子都出現了不能正常運行的情況。這個現象一度讓我們懷疑是否是CCM RAM在測試過程中遭到了破壞，導致我們在解決問題的道路上浪費了不少時間。
事實證明STM32的CCM RAM並沒有那麼脆弱，而解決問題時盡力從多個角度進行驗證，不放過所有可能出問題的環節之心態更爲重要。
在具體討論問題的原因之前，不妨先介紹一下STM32F4/STM32F3系列芯片上的CCM RAM。
CCM RAM介紹
ST的STM32F303, STM32F358, STM32F328, STM32F334系列和STM32F4的Advanced line系列芯片裏都有CCM(Core Coupled Memory) RAM。但仔細看系統架構圖會發現F3和F4的CCM RAM還是有不一樣的地方。如下面是STM32F303和STM32F427的架構圖：
F3和F4的CCM RAM都只能被內核訪問，DMA主設備沒有連接到CCM RAM，所以不能訪問它。從上圖我們還能看到，對於F303的CCM RAM它連接到了數據總線和指令總線上，所以32F303的CCM RAM既可以放數據也可以執行代碼。但32F427的CCM RAM只連接到了數據總線，所以F427的CCM RAM不能執行代碼。這一點需要注意。
數據和代碼放在CCMRAM的好處是，訪問和執行的速度更快。www.stmcu.com.cn網站上可以下載到AN4296的中文版本，這篇應用手冊裏詳細說明了怎麼從F303的CCM RAM裏執行代碼。在這裏就不再贅述了。下面接着講講前面在32F427上遇到的異常問題。
問題描述
客戶的產品做了一段時間的測試後發現一批板子全部出問題。客戶方面進行分析後用了一段簡單的點燈程序進行測試，發現當CSTACK放在不同的位置時程序表現不一樣。CSTACK放在SRAM中時，工作正常，但放在CCM RAM中就不能正常運行。從這個現象看很像是CCM RAM出問題了，且恰好只有經過測試的板子有問題，其他板子都沒有問題。
測試過程
拿到客戶的板子和測試代碼後很容易就重現了客戶描述的現象。
首先檢查了客戶測試代碼中的link文件。發現link文件寫的沒錯。【IAR環境】
/*###ICF### Section
handled by ICFeditor, don't touch! ****/
/*-Editor annotation file-*/
/*IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol__ICFEDIT_intvec_start__ = 0x08000000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__= 0x08000000;
define symbol__ICFEDIT_region_ROM_end__ = 0x081FFFFF;
define symbol__ICFEDIT_region_RAM_start__ = 0x20000000;
define symbol__ICFEDIT_region_RAM_end__ = 0x2002FFFF;
define symbol__ICFEDIT_region_CCMRAM_start__ = 0x10000000;
define symbol__ICFEDIT_region_CCMRAM_end__ = 0x1000FFFF;
/*-Sizes-*/
define symbol__ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__= 0x200;
/**** End of ICF editor section.###ICF###*/
define memory mem with size = 4G;
define region ROM_region = mem:[from__ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__];
define region RAM_region = mem:[from__ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__];
define region CCMRAM_region =mem:[from __ICFEDIT_region_CCMRAM_start__ to __ICFEDIT_region_CCMRAM_end__];
define block CSTACK with alignment =8, size = __ICFEDIT_size_cstack__ { };
define block HEAP with alignment =8, size = __ICFEDIT_size_heap__ { };
initialize by copy { readwrite };
do not initialize { section .noinit};
place at addressmem:__ICFEDIT_intvec_start__ { readonly section .intvec };
/*place at addressmem:__ICFEDIT_region_CCMRAM_start__ { block CSTACK };*/
place in CCMRAM_region {blockCSTACK};
place in ROM_region { readonly };
place in RAM_region { readwrite,block HEAP };
首先定義一個CCMRAM_region,然後通過”place in CCMRAM_region{block CSTACK};” 聲明將CSTACK放在CCM RAM中。但在接下來的測試中發現了一些新的現象。
測試一：
首先測試過程中發現板子連着ST-LINK在debug狀態下時，能正常運行。
只有斷開ST-LINK,重新上電後就不能正常工作了。
測試二：
爲了確認CCM RAM是不是真的壞了。另外寫了一個程序，將CSTACK放在SRAM中，然後在程序運行的時候對CCM RAM地址空間進行遍歷，對地址0x10000000 到0x1000FFFF空間逐次進行讀寫操作。發現程序正常運行，CCM RAM的讀寫正常。
實驗做到這裏，基本可以確定CCM RAM沒有損壞。但爲什麼CSTACK不能放到CCM RAM中呢？
然後我們又做了第三個實驗。
測試三：
對比拿到的壞板子的Optionbytes的值與默認值。逐個檢測不同的位是否和問題相關。發現BFB2這位的狀態會影響程序的運行。如果清除該位，即使將CSTACK放在CCM RAM中，程序也能正常運行。
原因分析
從上面的測試結果，發現問題跟Option bytes中的BFB2的狀態有關。查詢BFB2位的作用後搞清了問題的原因。我們先來說說BFB2做什麼用。STM32F427的Flash支持雙Bank. BFB2可以用來切換啓動時從Bank2啓動。我們來看看參考手冊中的描述：
如果想從Flash Bank2啓動，必須將BFB2位置1。如果此時boot引腳的配置是從用戶Flash啓動，芯片將先從系統bootloader啓動，然後跳轉到Bank2執行。
然後在應用筆記AN2606中，我們看到BFB2置1時的啓動流程，發現了問題所在。見下圖：
當BFB2置1時，在跳轉到用戶代碼（Bank2或者Bank1）之前，系統bootloader會檢查棧頂的位置是否在SRAM區域，也就是檢查是否落在0X20000000開頭的地址。如果不是，就會一直停在bootloader中，不繼續執行。這也就是我們前面看到的程序不能正常運行的原因。
當將BFB2位清除後，問題馬上解決了。而且對比當CSTACK設置在CCM RAM時還能正常工作的板子，發現這一位都是沒有置1的。
找到程序不能正常運行原因後，我們就從錯誤的方向回到正途，開始尋找Option bytes被修改的原因了。