STM32F103C8周期计数不匹配？预取缓冲区未按预期工作？

我太懂这种卡壳好久的感觉了——先夸一句，用DWT寄存器测精确周期这个操作真的很专业，比示波器还能抓细节。你提到在24MHz时钟下延迟完全符合设计值，但没说完后续的问题，我猜大概率是切换到其他时钟（比如STM32F1常用的72MHz）时，延迟周期就跟预期对不上了？结合你在ATSAM（84MHz）上跑完美的情况，我给你几个针对性的排查方向：

• FLASH等待周期的坑：STM32F1的Cortex-M3内核在高时钟下必须给FLASH加等待周期，比如72MHz时要设置1个等待周期（WS=1）。如果没开这个，CPU每次从FLASH取指令都会被卡住拖慢，汇编循环的实际执行周期就会比你计算的多，自然延迟就不准了。你可以去查STM32F1的参考手册，确认时钟配置时有没有同步设置FLASH_ACR寄存器的LATENCY位。

• 汇编指令的周期计算误差：你写的汇编延迟是不是硬编码了循环次数？比如24MHz下循环N次是目标延迟，那72MHz下循环次数得乘以3才对，但如果你的循环里的指令数算错了就会翻车。举个常见的错误例子：

delay_ms:
    mov r1, #1000
loop_inner:
    subs r0, r0, #1
    bne delay_ms
    subs r1, r1, #1
    bne loop_inner
    bx lr

这里面的分支指令在跳转成功和失败时的周期是不一样的（bne跳转成功是2周期，失败是1周期），如果你的计算没考虑这个，误差就会积累。另外，要注意DWT_CYCCNT寄存器会溢出归零，测长延迟时得处理溢出情况，不然读出来的周期数会不准。

• 调试环境的干扰：Atollic调试时，有没有开了某些调试选项（比如自动单步、数据断点）导致代码执行被打断？有时候调试模式下，ST-Link的介入会让指令执行变慢，你可以试试把程序烧录到芯片里，脱离调试器用示波器测实际延迟时间，对比DWT的数值，看看是不是调试环境搞的鬼。

• 时钟树配置的正确性：切换时钟频率时，你有没有确认PLL的倍频、分频系数全对？比如从24MHz切到72MHz，需要把PLLMUL设为9，HSE分频（如果用外部晶振）设为1，要是时钟树配置错了，实际CPU时钟根本不是你以为的频率，延迟肯定对不上。你可以用DWT测几个NOP指令的周期数，验证一下实际时钟频率是否和配置一致。

要是你能补充后续遇到的具体问题（比如是某特定时钟下延迟不准，还是有其他异常），再贴一下你的汇编延迟函数代码，我能给你更精准的建议。

内容的提问来源于stack exchange，提问作者user9687277