近日某論壇一STM32用戶反饋，使用STM32F103內(nèi)部時(shí)鐘，把系統(tǒng)時(shí)鐘配置成64MHz單片機(jī)就不跑了，配置成36MHz程序就正常妥妥的，頻率稍高點(diǎn)就容易導(dǎo)致死機(jī)。他貼出的代碼如下：

void RCC_Configuration(void)

{

RCC_DeInit();//將外設(shè) RCC寄存器重設(shè)為缺省值

RCC_HSICmd(ENABLE);//使能HSI

while(RCC_GetFlagStatus(RCC_FLAG_HSIRDY) == RESET);//等待HSI使能成功

//FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);

//FLASH_SetLatency(FLASH_Latency_2);

RCC_HCLKConfig(RCC_SYSCLK_Div1);

RCC_PCLK1Config(RCC_HCLK_Div2);

RCC_PCLK2Config(RCC_HCLK_Div1);

//設(shè)置 PLL 時(shí)鐘源及倍頻系數(shù)

RCC_PLLConfig(RCC_PLLSource_HSI_Div2, RCC_PLLMul_16);

結(jié)合他的問題描述及他貼出來的代碼，大致可以判斷出很可能是因?yàn)樗帘瘟酥噶铑A(yù)取和flash讀取等待延遲的參數(shù)配置而導(dǎo)致的異常。即上面兩條紅色標(biāo)注出來的代碼。

后來我明確地提醒他這點(diǎn)后，他似乎并沒及時(shí)反應(yīng)過來，還折騰了幾下才開啟了上述配置，問題最終得以解決。

其實(shí)，關(guān)于這個(gè)問題經(jīng)常有人遇到，尤其是那些基于STM32標(biāo)準(zhǔn)固件庫進(jìn)行開發(fā)或自行編程時(shí)的新手更容易碰到這個(gè)問題。主要原因是他們對上述兩行代碼的功能不了解，導(dǎo)致有意或無意的將庫例程中相關(guān)代碼屏蔽掉無視掉不做配置、或者配置不正確。

這里將這個(gè)問題再次分享出來，對上面兩行代碼簡單做些解釋。希望更多人對此有所知曉，少在這個(gè)地方走彎路。

這句FLASH_PrefetchBufferCmd();用來作為flash指令預(yù)取功能的使能或禁用。

現(xiàn)有STM32各個(gè)系列都是基于ARM cortexM內(nèi)核的微處理器，采用多級流水線的哈佛結(jié)構(gòu)，即一條指令的執(zhí)行分割為幾個(gè)階段，如取指、譯碼、執(zhí)行等，使得當(dāng)前指令的取指操作完成后就可以開始后續(xù)指令的取指、譯碼等操作，程序指令就這樣像流水一樣執(zhí)行下去，大大提高了指令的執(zhí)行效率。

具體到STM32各系列單片機(jī)，這個(gè)指令預(yù)取功能的開啟或關(guān)閉可以軟件配置，一般配置為開啟。要注意的是，芯片復(fù)位后不同的系列該功能有的默認(rèn)為開啟有的則默認(rèn)為關(guān)閉。比方STM32F1系列的flash指令預(yù)取功能就是默認(rèn)打開的，當(dāng)然你也可以關(guān)閉。其中，明確要求打開的情景就是當(dāng)那個(gè)AHB時(shí)鐘預(yù)分頻系數(shù)不等于1時(shí)。

再比如STM32F4系列，它的指令預(yù)取功能在芯片復(fù)位后是默認(rèn)關(guān)閉的，你可以自行打開。但明確要求關(guān)閉的場景就是芯片的供電電壓低于2.1V時(shí)。

其實(shí)，STM32F4的預(yù)取功能與STM32F1不盡一樣，STM32F4、STM32F2、STM32L4、STM32F7等系列芯片使用了ST的專利技術(shù)ART存儲(chǔ)加速器【Adaptive real-time memory accelerator】。該加速器使用指令預(yù)取隊(duì)列和分支跳轉(zhuǎn)緩存技術(shù)，從而提高 Flash 程序代碼執(zhí)行速度，使得CPU即使在其最高主頻下也能完美實(shí)現(xiàn)0等待執(zhí)行flash程序指令。

上面大致講了指令預(yù)取功能，預(yù)取主要是為了實(shí)現(xiàn)指令讀取和執(zhí)行的高效性。具體細(xì)節(jié)請參考相關(guān)技術(shù)手冊。我們知道CPU的運(yùn)行速度可調(diào)，可以很快，通常使用高速總線訪問FLASH接口控制器，F(xiàn)LASH控制器收到來自CPU的取指指令后然后去讀取相應(yīng)地址的指令或數(shù)據(jù)。Flash控制器自身的讀取速度相比CPU的高速請求來說可能會(huì)出現(xiàn)滯后，往往需要CPU做相應(yīng)的延時(shí)等待。為了讓CPU準(zhǔn)確及時(shí)讀取 Flash 數(shù)據(jù)，我們須根據(jù) CPU 時(shí)鐘頻率、FLASH控制器自身特性以及器件供電情況在Flash存取控制寄存器(FLASH_ACR)中正確地編程等待周期數(shù)(LATENCY)，類似上面提到的第二句代碼：

FLASH_SetLatency(FLASH_Latency_n);

這里的等待周期數(shù)視不同的STM32系列也各有差異，不妨以STM32F4為例：

下面是個(gè)關(guān)于STM32F4系列部分產(chǎn)品線的LATENCY設(shè)置的表格。從表格中可以看出LATENCY參數(shù)的設(shè)置與CPU的時(shí)鐘、電源電壓都有關(guān)系。另外，當(dāng)電源電壓在2.1V以下上要關(guān)閉預(yù)取功能。

在設(shè)置上面的等待周期參數(shù)時(shí)，選擇合適的就好。不難理解，設(shè)置太大了影響CPU性能的充分發(fā)揮，太小了容易導(dǎo)致異常。

具體回到開頭的案例，它出現(xiàn)死機(jī)問題，極可能是因?yàn)闆]有合理配置等待周期參數(shù)導(dǎo)致異常，因?yàn)樗帘瘟藚⒖祭讨心莾删渑渲么a，即使用其默認(rèn)功能，對于STM32F1，指令預(yù)取功能默認(rèn)為開啟。而STM32F1系列芯片的latency默認(rèn)值即為0，無等待。這樣的話，當(dāng)他把時(shí)鐘調(diào)高到一定程度時(shí)出現(xiàn)死機(jī)就不難理解了。

另外，當(dāng)他反饋時(shí)鐘調(diào)高產(chǎn)生異常時(shí)，我還給他提醒了注意檢查VDDA的電源情況。我碰到有人遇到因VDDA沒接好使得PLL不正常的情況。我們知道，對于STM32芯片，調(diào)高其工作時(shí)鐘，往往借助于鎖相環(huán)。而PLL的供電來自VDDA，如果PLL沒有被正常供電，也是個(gè)非常隱蔽的麻煩。曾經(jīng)有個(gè)客戶為此折騰好久，才愿沉下心來檢查其“壞品”的電源，結(jié)果發(fā)現(xiàn)有個(gè)VDDA腳虛焊。一直以芯片低頻沒問題，頻率高了就異常為由懷疑芯片品質(zhì)問題而耽誤時(shí)間。

最后給點(diǎn)建議，做STM32開發(fā)的話，尤其是新手，如果參照ST的官方例程的話，有些配置在沒看懂的情況下不要輕易屏蔽或修改。我碰到多個(gè)類似本案隨意屏蔽例程中的初始化配置代碼或斷言代碼出現(xiàn)異常，自己又找不到方向的。另外，盡可能使用ST官方的stm32cubeMx圖形配置工具做基本的配置，通過它來生成初始化配置文件，這樣方便省事很多。當(dāng)然，即使使用STM32CUBEMX配置也不是萬能的。比方：曾經(jīng)有人使用STM32F0開發(fā)產(chǎn)品，用CUBEMX配置初始化文件，剛開始配置時(shí)時(shí)鐘選擇得比較低， STM32CubeMx自然根據(jù)他選擇的時(shí)鐘做了相關(guān)參數(shù)配置。后來他自己在用戶代碼里手動(dòng)調(diào)高了時(shí)鐘，而不知相應(yīng)調(diào)整跟FLASH讀取等待有關(guān)的參數(shù)，也是發(fā)生跟本案同樣的情況。所以呢，如果能對原理有更多更深的把握那是再好不過了。