近日某論壇一STM32用戶反饋，使用STM32F103內(nèi)部時鐘，把系統(tǒng)時鐘配置成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ù)

RCC_PLLConfig(RCC_PLLSource_HSI_Div2, RCC_PLLMul_16);

結(jié)合他的問題描述及他貼出來的代碼，大致可以判斷出很可能是因為他屏蔽了指令預(yù)取和flash讀取等待延遲的參數(shù)配置而導(dǎo)致的異常。即上面兩條紅色標(biāo)注出來的代碼。

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

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

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

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

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

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

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

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

上面大致講了指令預(yù)取功能，預(yù)取主要是為了實現(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的高速請求來說可能會出現(xiàn)滯后，往往需要CPU做相應(yīng)的延時等待。為了讓CPU準(zhǔn)確及時讀取 Flash 數(shù)據(jù)，我們須根據(jù) CPU 時鐘頻率、FLASH控制器自身特性以及器件供電情況在Flash存取控制寄存器(FLASH_ACR)中正確地編程等待周期數(shù)(LATENCY)，類似上面提到的第二句代碼：

FLASH_SetLatency(FLASH_Latency_n);

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

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

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

具體回到開頭的案例，它出現(xiàn)死機(jī)問題，極可能是因為沒有合理配置等待周期參數(shù)導(dǎo)致異常，因為它屏蔽了參考例程中那兩句配置代碼，即使用其默認(rèn)功能，對于STM32F1，指令預(yù)取功能默認(rèn)為開啟。而STM32F1系列芯片的latency默認(rèn)值即為0，無等待。這樣的話，當(dāng)他把時鐘調(diào)高到一定程度時出現(xiàn)死機(jī)就不難理解了。

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

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