老哥，我之前在做Cortex-M7裸机的WCET分析时踩过不少坑，针对你说的带指令缓存、只能关闭动态分支预测（静态关不掉）的单线程无中断场景，给你整理几个实用的方向，都是我实际用过或者身边朋友验证过的：

一、手动分析+硬件计数器实测（最落地的低成本方案） #

这是我最推荐的，裸机无中断的环境没有干扰，结果准，不用复杂工具：

• 先扒出循环的汇编代码：用你的交叉编译器（比如arm-none-eabi-gcc）加-S选项编译，把循环对应的汇编段抽出来，对着Cortex-M7的指令集手册，算每条指令的最坏情况周期数——比如指令缓存未命中时的加载周期、静态分支预测失败的跳转周期，都要算进去。
• 用DWT计数器精准计数：STM32H7的DWT有个CYCCNT寄存器，能精准统计CPU的时钟周期。因为是单线程无中断，跑循环的时候不会被打断，数据绝对干净。
• 构造最坏场景：
  • 缓存最坏情况：在循环前跑一大段无关代码，把指令缓存完全占满，让循环代码第一次执行时完全未命中缓存，记录这个状态下的周期数。
  • 分支预测最坏情况：Cortex-M7的静态分支预测规则是向后跳转默认预测会发生，向前跳转默认预测不发生，如果你的循环结构是向前跳转退出（比如do-while的反向条件），要构造每次预测失败的场景，记录对应的周期。
• 取最大值：多跑几次，排除偶然波动，最大的那个周期数就是循环的WCET候选。

二、半静态分析+实测结合（兼顾精度和效率） #

如果循环比较复杂，纯手动算太麻烦，可以这么搞：

• 静态拆分基本块：把循环拆成几个基本代码块（比如循环体、条件判断、跳转），分别计算每个块在缓存命中/未命中、分支预测成功/失败下的周期数。
• 固定编译输出：用固定的编译器优化选项（比如-O2），并且禁用编译的随机化选项，保证每次编译出的汇编指令都一样，避免分析的指令和实际跑的不一样。
• 用ETM跟踪辅助：如果有条件的话，开启STM32H7的ETM（嵌入式跟踪宏单元），它能完整记录循环执行的每一条指令和对应的周期，直接捕捉到最坏情况的执行路径。

三、开源工具辅助模拟（不用付费工具的折中方案） #

如果不想纯手动算，可以用开源工具做模拟，再结合实测验证：

• 用llvm-mca模拟：这是LLVM自带的代码分析工具，能模拟CPU的流水线、缓存、分支预测行为。你只需要把循环的汇编代码喂进去，加上-mcpu=cortex-m7参数，它会输出迭代的吞吐量、指令延迟等数据，其中最坏情况的迭代周期可以作为参考。
• 注意：模拟毕竟是理论值，要和DWT的实测数据对比，因为实际硬件的总线延迟、缓存行对齐这些细节，模拟可能没完全覆盖到。

四、代码/硬件优化（从根源降低WCET的不确定性） #

如果你的项目允许改代码或者调整硬件配置，这几个方法能让WCET的估算变得简单很多：

• 把循环代码放到ITCM：STM32H7的ITCM是紧耦合内存，零等待访问，没有缓存未命中的问题。把循环体编译到ITCM后，每条指令的执行周期都是固定的，WCET就是循环次数乘以单循环的周期数，直接就能算准。
• 调整循环结构适配静态分支预测：把循环改成标准的向后跳转结构（比如普通的for循环），让静态分支预测每次都命中，消除分支预测失败的周期波动。
• 关闭指令缓存：如果性能允许的话，直接关掉指令缓存，这样所有指令的执行周期都是固定的，不用考虑缓存的影响，估算起来超简单。

对了，我之前帮朋友做过电机控制的循环WCET分析，就是用DWT+ITCM的方案，结果和实际运行的最坏情况完全吻合，你可以试试。如果你的循环有特殊的结构（比如嵌套循环、复杂条件判断），可以再细说，我给你抠更细的点～