近日某論壇一STM32用戶反饋，使用STM32F103內部時鐘，把系統時鐘配置成64MHz單片機就不跑了，配置成36MHz程序就正常妥妥的，頻率稍高點就容易導致死機。他貼出的代碼如下：

void RCC_Configuration(void)

{

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

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);

//設置 PLL 時鐘源及倍頻系數

RCC_PLLConfig(RCC_PLLSource_HSI_Div2, RCC_PLLMul_16);

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

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

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

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

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

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

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

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

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

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

FLASH_SetLatency(FLASH_Latency_n);

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

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

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

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

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

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