1. 问题现象
客户使用的是 STM32H753，使用 ST 官方的 SBSFU V2.3 做安全启动，反馈在从SBSFU 跳转到用户程序 APP 的过程中小概率会卡住。
2. 问题分析
在接到问题后，与客户沟通，尽可能地了解问题背景，并询问客户为何可以断定是在跳转的过程中卡住，而不是在 APP 启动后出现问题？在沟通的过程中，进一步了解到，原来客户在跳转之前后和跳转之后都是通过一个 GPIO 翻转来判断程序是否运行到此，因为在跳转之前打印信息是关闭了的，而在 APP 启动之初，串口还没有来得及初始化就已经出现了问题，因此，只能采用最原始的 GPIO 翻转来简单判断程序的运行轨迹。
刚开始以为是流水线或者缓存出现了问题，于是建议关闭指令缓存和数据缓存，以及清除流水线后(ISB)后再执行跳转，结果经过几天验证问题依旧。后来发现客户使用的是H753 Y 版本，且运行在 480MHz，但是 Y 版本的 H753 当前早已停产，市场上的都是市场残留，且 Y 版本的 H753 最高主频为 400MHz，也就是说客户当前的 MCU 是处于超频状态，且最终客户量产时的芯片必然是最新的 V 版本。于是客户做了两个测试,测试温度：
60℃，SBSFU v2.3：
Test 1：基于 Y 版本，主频跑 400MHz。
Test 2：使用 V 版本，还是跑 480MHz。
测试结果：
Test 1 -> 不再重现 !
Test 2 -> 问题依旧

问题看起来与主频有关，难道主频只能跑 400MHz ?
于是要客户接着做测试 :
Test 3 : V 版本, 主频跑 400 MHz
Test 4 : 使用 ST 官方的 NUCLEO-H753 板子，同样的测试条件，跑最高主频 480 MHz

测试结果 :
Test 3 ->不再重现.
Test 4 ->由于客户弄坏了一块 H753-NUCELO 板子，当前只剩下一块，不想再冒弄坏的风险，所以没测。
问题有点莫名其妙，当前看起来 SBSFU 对主频有所限制？ 但是勘误手册中没有半点提示啊。要客户将跳转的代码发过来仔细检查，在比较客户跳转代码与 CubeMx 示例代码时，发现示例代码中在 SUSFU 初始化部分带有部分些许 IO 补偿的代码，于是要客户打开IO 补偿试下，于是：
测试 5：打开 IO 补偿 -> 测试结果 OK！

同样的 V 版本芯片，最高主频 480MHz,环境温度 60℃，只不过打开了 IO 补偿，或者降频到 400MHz, 问题不再重现 ! 毫无疑问，问题与 IO 补偿，与主频有关！从相关文档查看 IO 补偿的信息，知道 IO 补偿一般与 IO 引脚的斜率有关，还会改善对电源的影响。 于是想到 VCAP 引脚，于是要来客户的 VCAP 相关的外围电路和跳转时的波形图：







从上图可以明显看出，H753 的两个 VCAP 引脚外围没有连接在一起，于是存在一个电压差。但是 NUCELO-H753 的板子这两个引脚从外边是连接在一起的。



完整版请查看：附件