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程序指令。

上面大致介绍了指令预取功能，预取主要是为了实现指令读取和执行的高效性。具体细节请参考STM32和ARM cortex内核的相关技术手册。

我们知道CPU的运行速度可调、可以很快，通常使用高速总线访问FLASH接口控制器，FLASH控制器收到来自CPU的取指指令后然后去读取相应地址的指令或数据。Flash控制器自身的读取速度相比CPU的高速请求来说可能会出现滞后，往往需要CPU做相应的延时等待。为了让CPU准确及时读取Flash 数据，我们须根据 CPU 时钟频率以及器件供电情况在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读取等待有关的参数，也是发生跟本案同样的情况。