因为while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY)!=SET);进入hardfault中断死掉

因为while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY)!=SET);进入hardfault中断死掉，我用的是stmf030C6T6，内部时钟，倍频到48MHZ，从硬件仿真追踪到进入hardfault前在执行while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY)!=SET); 而且是有概率性（快速关断就容易触发，平时很难）的，寄存器的的数据也正常啊  至于执行这一句为什么会进入实在找不到头绪，，，望大神能来解答下

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

我自己解决了  来分享下吧

1、定位进入hardfault中断之前执行的语句

      方式网上很多，都不难，自己想办法也用能排除定位出来，就不赘述了，有什么疑问可以留言哈  以为是我之前看到比较全比较的定位方法：

网址：https://blog.csdn.net/u012075442/article/details/50931354

注：网上有许多方法中有一步“”打开Peripherals >Core Peripherals >Fault Reports打开异常发生的报告”，这个是只能有允许对内核访问权限的芯片才行，例如我这次用的stmf030C6T6，内核是CortexM0就不行。

2、查看出毛病语句

    从网上多数大神总结出来的，一般hardfault 是由内存（越界或者溢出）引起的

 可点开了库里的RCC_GetFlagStatus，怎么看没毛病 于是乎我尝试性的去掉（uint8_t）强制转换，为什么呢，男人的直觉吧

修改后 为了保险一点我前面多加10步空执行吧（简直蠢，中学老师控制变量去哪里了，等下就知道给造成误判断麻烦），而且空执行延时的效果应该和下面while等待应该是一样的效果

几十轮debug 测试后  明显感觉进入hardfault的概率下降了很多

好吧  就此我一度误以为是强制转换的问题

 

可是怎么样都无法完全消灭，可是领导要东西  

 while（1）

{急急急}  

无奈，当时就把hardfault里的while（1）里去掉  

debug 一试  哈哈哈  虽然还是会进入hardfault 不过 能出来继续回到while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY)!=SET);

几个轮回后就好了  不影响板子的功能  交差

 

别急，求知欲告诉我，要治本，要探索

到此我们可以先得出一个结果：错误 肯定是由PLL锁相环或者系统时钟引起的

于是乎 我又尝试性的将倍频系数降低下试试 （这什么垃圾博主  天天蒙 能不科学认真严谨一点 啊？ 啊！）

亲测下来  哇咔咔 居然好了一次都没进  嗯~本着科学 严谨 认真 →.→我决定做一个自动化测试

result：10000次 图上的88次故障我瞎设的初始值

根据这个结果结合我之前的加while（num--）空语句，我想起好像系统时钟倍频之后是需要一定机器周期时间才能稳定

来来 查查flash手册

果不其然

在flash库里找到

结论：在配置系统时钟的添加一个函数 FLASH_SetLatency（flash储存器延时）就能解决，之前快速关断引起了flash不稳定；

可能这后面解释得也不好，赶时间没那么详细，有问题可以留言哈~