查看: 4230|回復: 0
打印 上一主題 下一主題

一個(gè)關(guān)于使用STM32F4芯片CCM RAM時(shí)的異常分析

[復制鏈接]
跳轉到指定樓層
樓主
發(fā)表于 2017-1-12 11:12:05 | 只看該作者 |只看大圖 回帖獎勵 |倒序瀏覽 |閱讀模式
前言
有客戶(hù)用STM32F427芯片,程序將CSTACK放在CCM RAM中,結果測試過(guò)一段時(shí)間的板子都出現了不能正常運行的情況。這個(gè)現象一度讓我們懷疑是否是CCM RAM在測試過(guò)程中遭到了破壞,導致我們在解決問(wèn)題的道路上浪費了不少時(shí)間。
事實(shí)證明STM32的CCM RAM并沒(méi)有那么脆弱,而解決問(wèn)題時(shí)盡力從多個(gè)角度進(jìn)行驗證,不放過(guò)所有可能出問(wèn)題的環(huán)節之心態(tài)更為重要。
在具體討論問(wèn)題的原因之前,不妨先介紹一下STM32F4/STM32F3系列芯片上的CCM RAM。
CCM RAM介紹
ST的STM32F303, STM32F358, STM32F328, STM32F334系列和STM32F4的Advanced line系列芯片里都有CCM(Core Coupled Memory) RAM。但仔細看系統架構圖會(huì )發(fā)現F3和F4的CCM RAM還是有不一樣的地方。如下面是STM32F303和STM32F427的架構圖:
F3和F4的CCM RAM都只能被內核訪(fǎng)問(wèn),DMA主設備沒(méi)有連接到CCM RAM,所以不能訪(fǎng)問(wèn)它。從上圖我們還能看到,對于F303的CCM RAM它連接到了數據總線(xiàn)和指令總線(xiàn)上,所以32F303的CCM RAM既可以放數據也可以執行代碼。但32F427的CCM RAM只連接到了數據總線(xiàn),所以F427的CCM RAM不能執行代碼。這一點(diǎn)需要注意。

數據和代碼放在CCMRAM的好處是,訪(fǎng)問(wèn)和執行的速度更快。stmcu.com.cn網(wǎng)站上可以下載到AN4296的中文版本,這篇應用手冊里詳細說(shuō)明了怎么從F303的CCM RAM里執行代碼。在這里就不再贅述了。下面接著(zhù)講講前面在32F427上遇到的異常問(wèn)題。

問(wèn)題描述
客戶(hù)的產(chǎn)品做了一段時(shí)間的測試后發(fā)現一批板子全部出問(wèn)題?蛻(hù)方面進(jìn)行分析后用了一段簡(jiǎn)單的點(diǎn)燈程序進(jìn)行測試,發(fā)現當CSTACK放在不同的位置時(shí)程序表現不一樣。CSTACK放在SRAM中時(shí),工作正常,但放在CCM RAM中就不能正常運行。從這個(gè)現象看很像是CCM RAM出問(wèn)題了,且恰好只有經(jīng)過(guò)測試的板子有問(wèn)題,其他板子都沒(méi)有問(wèn)題。
測試過(guò)程
拿到客戶(hù)的板子和測試代碼后很容易就重現了客戶(hù)描述的現象。
首先檢查了客戶(hù)測試代碼中的link文件。發(fā)現link文件寫(xiě)的沒(méi)錯!綢AR環(huán)境】
/*###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 };
首先定義一個(gè)CCMRAM_region,然后通過(guò)”place in CCMRAM_region{block CSTACK};” 聲明將CSTACK放在CCM RAM中。但在接下來(lái)的測試中發(fā)現了一些新的現象。

測試一:
首先測試過(guò)程中發(fā)現板子連著(zhù)ST-LINK在debug狀態(tài)下時(shí),能正常運行。
只有斷開(kāi)ST-LINK,重新上電后就不能正常工作了。
測試二:
為了確認CCM RAM是不是真的壞了。另外寫(xiě)了一個(gè)程序,將CSTACK放在SRAM中,然后在程序運行的時(shí)候對CCM RAM地址空間進(jìn)行遍歷,對地址0x10000000 到0x1000FFFF空間逐次進(jìn)行讀寫(xiě)操作。發(fā)現程序正常運行,CCM RAM的讀寫(xiě)正常。
實(shí)驗做到這里,基本可以確定CCM RAM沒(méi)有損壞。但為什么CSTACK不能放到CCM RAM中呢?
然后我們又做了第三個(gè)實(shí)驗。
測試三:
對比拿到的壞板子的Optionbytes的值與默認值。逐個(gè)檢測不同的位是否和問(wèn)題相關(guān)。發(fā)現BFB2這位的狀態(tài)會(huì )影響程序的運行。如果清除該位,即使將CSTACK放在CCM RAM中,程序也能正常運行。

原因分析
從上面的測試結果,發(fā)現問(wèn)題跟Option bytes中的BFB2的狀態(tài)有關(guān)。查詢(xún)BFB2位的作用后搞清了問(wèn)題的原因。我們先來(lái)說(shuō)說(shuō)BFB2做什么用。STM32F427的Flash支持雙Bank. BFB2可以用來(lái)切換啟動(dòng)時(shí)從Bank2啟動(dòng)。我們來(lái)看看參考手冊中的描述:
如果想從Flash Bank2啟動(dòng),必須將BFB2位置1。如果此時(shí)boot引腳的配置是從用戶(hù)Flash啟動(dòng),芯片將先從系統bootloader啟動(dòng),然后跳轉到Bank2執行。
然后在應用筆記AN2606中,我們看到BFB2置1時(shí)的啟動(dòng)流程,發(fā)現了問(wèn)題所在。見(jiàn)下圖:
當BFB2置1時(shí),在跳轉到用戶(hù)代碼(Bank2或者Bank1)之前,系統bootloader會(huì )檢查棧頂的位置是否在SRAM區域,也就是檢查是否落在0X20000000開(kāi)頭的地址。如果不是,就會(huì )一直停在bootloader中,不繼續執行。這也就是我們前面看到的程序不能正常運行的原因。

當將BFB2位清除后,問(wèn)題馬上解決了。而且對比當CSTACK設置在CCM RAM時(shí)還能正常工作的板子,發(fā)現這一位都是沒(méi)有置1的。
找到程序不能正常運行原因后,我們就從錯誤的方向回到正途,開(kāi)始尋找Option bytes被修改的原因了。




融創(chuàng )芯城首創(chuàng )全球工程師,利潤分享計劃,只要你邀請朋友注冊融創(chuàng )芯城,所注冊的朋友產(chǎn)生的收益,你就分成!

您需要登錄后才可以回帖 登錄 | 立即注冊

本版積分規則

關(guān)于我們  -  服務(wù)條款  -  使用指南  -  站點(diǎn)地圖  -  友情鏈接  -  聯(lián)系我們
電子工程網(wǎng) © 版權所有   京ICP備16069177號 | 京公網(wǎng)安備11010502021702
快速回復 返回頂部 返回列表
午夜高清国产拍精品福利|亚洲色精品88色婷婷七月丁香|91久久精品无码一区|99久久国语露脸精品|动漫卡通亚洲综合专区48页