
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 的板子这两个引脚从外边是连接在一起的。 完整版请查看:附件 |
LAT1153_使用STM32H753从SBSFU跳转到APP失败_v1.0.pdf
下载465.72 KB, 下载次数: 1
NUCLEO-H723ZG开发板试用 ——串口点灯测试
经验分享 | STM32H7 EXTI + SPI +DMA 双缓冲应用演示
【经验分享】STM32H7时钟
拷打cubemx【003】——找不到的芯片包
【2025·STM32峰会】GUI解决方案实训分享5-调通板载的NRF24L01 SPI接口并使用模块进行无线通信(发送和接收)
【2025·STM32峰会】GUI解决方案实训分享4-使用MVP架构从硬件外设读取数据并显示到图形界面、从图形界面发送指令控制硬件外设
【2025·STM32峰会】GUI解决方案实训分享3-搭建空白TouchGFX例程并实现简单的功能(含硬件部分的串口打印)
【2025·STM32峰会】GUI解决方案实训分享2-编译运行TouchGFX咖啡机例程(含桌面仿真)
【2025·STM32峰会】+TouchGFX实现动态进度显示以及界面切换
【2025·STM32峰会】+使用TouchGFX快速创建GUI