MCU主频刚提上去就跑飞，先检查Flash等待周期

PLL已经锁定，分频也算对了，程序一切换到高主频却立刻HardFault，或者在低电压、高温时偶发跑飞。问题可能不在时钟源，而在Flash还按低频访问。内核时钟变快后，每个周期更短，片上Flash的物理读取时间却不会同步缩短。等待周期没提前增加，CPU可能在指令或常量尚未稳定时就继续执行，于是故障看起来随机，实质上是访问时序超界。

内核能跑多快，不等于Flash能一拍返回

MCU内核通常可在较高频率工作，片上Flash阵列的读取时间受工艺、供电和温度限制。控制器通过插入等待状态，把一次取指拉长到Flash能够可靠输出的时间。所需等待数并非只由主频决定，还与供电电压范围、芯片系列、加速器配置有关。预取和指令缓存可以提高平均吞吐，却不能把违反手册的基础等待状态变成安全配置。代码在SRAM中运行正常、回到Flash就出错，是很有价值的定位线索。

图1　MCU开发板实物用于对应内核、片上Flash、供电与时钟配置的真实载体。

升频与降频的配置顺序相反

升频时，应在切换系统时钟前把Flash等待状态提高到目标频率所需值，并按器件要求配置预取或缓存；确认写入生效后，再启用并锁定PLL、设置总线分频、切换系统时钟。降频时则先把系统时钟降下来，再减少等待状态。若先减延迟再降频，短暂窗口也可能越界。电压调节器档位需要与目标频率匹配的器件，还要先完成电压尺度切换并等待就绪。顺序是启动代码的一部分，不能只保留最终寄存器值。

图2　另一类MCU板卡用于提醒，不同系列的Flash与电源时序表不能相互照搬。

缓存会让问题变得时好时坏

启动路径短、循环代码已进入缓存时，错误配置可能暂时不暴露；中断进入未缓存区域、执行大函数、读取Flash常量或缓存失效后才触发。调试器单步会改变预取节奏，也可能让故障消失。温度升高或电压降低使访问裕量变小，量产边界才复现。排查时可关闭或清空缓存做对照，也可把关键测试函数搬到SRAM执行，比较故障是否随取指介质变化。不要把“重启一次好了”当成时钟配置已经可靠。

图3　不同控制器板卡的Flash与调试接口位置，有助于安排SRAM运行和边界测试。

读取回寄存器，还要做最坏工况验证

配置后读回Flash延迟、系统时钟源和各总线分频，确认硬件真正进入目标状态。用当前芯片参考手册而不是相近型号的示例代码查表，覆盖最低工作电压、最高温度和最高目标频率。运行能造成缓存失效、密集Flash常量访问和频繁中断的测试，再观察HardFault状态寄存器和故障地址。Bootloader与应用若都会改时钟，必须约定交接状态；从低频升级程序跳到高频应用时，不能假设Flash配置已由上一阶段正确完成。

图4　时钟与Flash等待关系图把配置顺序、取指窗口和故障点放在一条时间线上。

库函数不会替你覆盖所有边界

厂商时钟初始化函数通常按某个电压档和目标频率配置延迟，但自定义启动、低功耗唤醒、动态变频和Bootloader跳转会打破默认前提。代码评审要把Flash等待状态与系统频率放在同一个原子切换流程里，失败时回退到安全时钟。若支持运行时降压，应先降频再降压；升压后确认就绪，才允许升频。还要核对数据Flash、外部QSPI或XIP存储，它们有各自的等待、采样边沿和校准要求。把故障处理器中的CFSR、HFSR、BFAR/MMFAR以及堆栈现场保留下来，可以区分取指总线错误、非法指令和普通软件越界，避免所有跑飞都归因于PLL。编译器和链接布局会改变故障暴露方式。优化等级变化后，热点循环可能缩短或跨越新的Flash行，常量池位置也会移动，因此同一错误配置可能在一次编译中稳定、下一次编译中随机。ECC或奇偶校验开启的器件，时序超界还可能先表现为可纠正错误计数增加，再升级为总线故障。量产测试可读取并清零相关错误状态，在高低温与最低电压下运行Flash压力程序。若系统支持在线升级，升级前后的Bootloader、选项字节和缓存策略必须兼容。时钟初始化失败时不要继续尝试目标高频，应该回到内部安全时钟并留下故障码，保证设备仍能被诊断和恢复。启动代码还要防止中断在切换中途进入。若中断处理函数位于Flash，且此时等待状态与主频暂时不匹配，故障会难以复现。关键切换窗口应按器件建议屏蔽或控制中断，并确保异常向量和回退路径可用。

提高主频是一条跨越电源、Flash、总线和时钟源的切换链。目标寄存器值都正确，不代表切换过程中的每一个瞬间都安全；顺序和边界工况同样必须验证。

你们的动态变频代码，会把Flash等待状态的升降顺序写成自动检查项吗？