使用HSI无法将PLL倍频到64M的话题
某客户使用STM32F103芯片开发产品，程序代码基于STM32F1的标准库进行开发。在设计初期，他用最小核心板调试程序。样板上有个8MHz外部晶体，但他一直使用HSI。所以最终产品就没有放置外部8M晶体。但等样机回来后，发现用内部HSI作为时钟源时，系统时钟无法通过PLL倍频到64MHz，最高只能到48MHz可以正常运行，再高的话，程序执行后就会进入硬件故障中断，即HardFault_Handler()。
但之前程序在最小核心板上是调试通过了的，于是他试着把之前最小核心板上的外部晶体拆掉，程序竟然也跑不起来了。
这似乎表明，如果没有外部晶体，使用HSI就无法倍频至64MHz。这就奇怪了？！难道不接外部晶体，内部HSI就无法倍频至64MHz吗？
到此，客户反映的情况应说很清楚了。对于STM32F1系列而言，不论是手册的表述还是实际应用，我们知道即使使用HSI的作为时钟源，通过PLL是完全可以倍频到64MHz的。
如果说只是单纯地倍频到不了64MHz的话，原因可能性较大的有2种情况：
第一、因为疏忽，配置参数出现失误导致超频。这也可能导致芯片功能异常。
第二、MCU的供电有问题。一般表现在MCU的电源脚没有全部接上电源，即只是部分电源脚接上了电源；再一种可能性就系统供电能力不足。因为MCU主频越高，功耗也相对越高。如果供电跟不上的话也会出现性能异常。
具体到本案例，上面第一种情况可以很快排除。因为在外接晶体时，使用HSI还是可以倍频到64MHz的。现在问题的症结就是，为什么只有外接晶体时，HSI才能被倍频到64MHz。
要解开这个症结，就有必要了解下基于STM32F1标准固件库芯片启动时的有关时钟的基本配置流程。
芯片复位后首先要运行一个启动文件，启动文件里就有对系统时钟的一些基本配置。不妨就以STM32F1系列为例【如基于标准固件库，其它STM32系列在这点上基本一样】。
启动文件里面有个SystemInit( )函数，它又调用了SetSysClock()时钟配置函数。该函数就是做有关系统时钟、外设时钟、AHB时钟以及指令预取和Flash读取等待延时等配置的。在SetSysClock()里会根据默认的或用户预定义的系统时钟频率去对有关时钟、指令预取、FLASH等待进行配置。
对于STM32F103xx，用户若不对代码额外调整，启动代码里默认使用HSE 8Mhz,SYSTEM CLOCK 为72MHz来进行配置。如果外部晶振没接上，就默认使用HSI作为系统时钟。
具体结合到这里，外接晶体时，启动时默认使用HSE并通过PLL倍频到72MHz；没有外接晶体时，直接使用HSI作为系统时钟。之后用户自己重新利用HSI进行系统时钟配置。若经前者的途径过来，用户就可以将PLL倍频到64MHz,而经后者却不行。这两种操作有哪些差别呢？
启动代码默认HSI作为系统时钟，一路默认设置，并无过多代码。那我们重点看看SetSysClock()调用到的SetSysClockTo72()的代码，看能否有所发现，或者说代码里有什么特别的没有。
从该函数里可以看到红色三角形标注的代码，令人想起有关指令预取和FLASH等待状态的配置。那个flash等待状态的配置，不同的系统时钟下，参数是不一样的。系统时钟频率越高，这个等待状态参数值越大。毕竟FLASH控制器读取FLASH数据的速度是很有限的，而CPU对指令的运行速度可以很高，当CPU对指令的访问速度高于或远高于FLASH控制器所能提供的速度时，就涉及到读取等待和指令预取问题。结合CPU的时钟和FLASH本身的读取时间，打开指令预取，合理配置FLASH等待就很关键，否则当CPU时钟高到一定程度时就会出现功能异常。
结合本案例来看，当板上放了晶体时，刚好符合启动代码默认外部HSE作时钟源配置出72MHz的条件,并在这个过程中开启指令预取和配置了等待延时。后面当用户把时钟源换为HSI并利用PLL倍频到64Mhz时,就无需再做指令预取和FLASH等待配置，系统也能正常运行。当板子上没放外部晶体时，启动代码默认HSI作为系统时钟，且该过程没做指令预取和FLASH等待的配置【因系统时钟频率低，此时也的确不需要额外设置，使用默认0等待即可】。之后，当用户使用HSI利用PLL进行倍频时，他自己也没做指令预取和FLASH等待的配置，当系统时钟频率配置较高时出现功能异常也就不意外了。后来建议客户在使用HSI对PLL进行倍频前，加入上面提到的相关配置代码后就得以解决。
其实，如果客户的软件开发是基于ST公司推出的工具STM32CubeMx来进行的话，类似上面的问题是比较容易避免的。对于刚接触STM32的人来说，使用STM32CubeMx可以大大节省开发时间。当然，任何东西都有其两面性，工具给我们带来方便的同时，有时可能会让我们对一些基本的、细节的东西缺乏相应的了解和把握。所以，条件允许的话，多研读技术手册、多分析参考代码也是有必要的。
==================================
扫描或长按二维码可关注公众号