
1. 问题现象 客户使用 STM32H750VBT6,通过 QSPI 外扩了一个 4M 的 NOR FLASH,采用memory map 模式。当程序跳转运行到外设 FLASH 后,大约两个小时后程序死机。 客户使用的 IDE 是 KEIL,此问题可以固定重现。 在 KEIL 调试模式下重现问题时,通过多次观察发现,程序死的位置总体上会停在两个位置,并不是同一个位置。一个是 TIM15函数的入口;另一个是进入中断函数后的一个赋值语句。 2. 问题分析及测试 通过拜访客户,观察到死机位置处于即将进入 TIM15 中断入口处,但还未进入之时。查看客户的原理图,发现两个 VCAP 并未从外部相连,于是要求客户直接从外部将此两个引脚飞线短连。 但是,后来经测试问题仍然重现。 又观察到 PC13 连接为 GPIO 输出引脚,用于驱动一外部组件。 考虑到备份域相关的一些引脚其驱动能力相对弱一些,于是让客户将 PC13 引脚断开后再测试,结果问题仍然重现。 上面是一些硬件相关的怀疑点,经测试结果来看,与此问题无关。 看来主要可能还是软件方面的问题。 在软件上确定客户已经打开了 IO 补偿功能,但 IO 速度设置的是 HIGH,于是让客户修改成 “VERY_HIGH”,经测试问题仍然存在。 由于之前发生过一个从低功耗唤醒后死机的问题,是与 Cache 相关的问题,于是要测试下将 CACHE 关闭的情况。 这次经测试客户反馈问题没现重现 ! 但客户同时也反馈,之前的代码也存在稍微修改一处代码,问题就不再重现的现象,没有找到具体规律。 这次代码修改也没排除这种可能性。 为了让关闭 Cache 的方法更具效力,于是让客户在调试模式下通过手动关闭 CACHE的方式,代码仍然保持为原先可以重现问题的代码。如下图所示 : ![]() 如上图所示,在代码运行到使用 CACHE 后一行设置断点,当程序停下来后,打开 Sys Ctrl/Cfg 窗口(菜单 view->system viewer->Core peripherals->system control and configuration),将对应的位去掉。 最终客户反馈,关闭 DC,或者 IC 任何一个或者两个都关闭,问题现象消失。 至此可以确定地是,此问题与 CACHE 相关 ! 于是查看客户的 MPU 相关配置,并将 Cube 包里的 H750 示例工程中的 MPU 配置发给客户测试下,但问题仍然存在。 接下来查看勘误手册,发现 2.4.4 节有 QSPI 相关的内容: ![]() 这里有提到在 QSPI 外设 FLASH 并工作在 memory-mapped 模式的时候,当读取由FSIZE 定义的最后一个字节的时候,不管内容如何,有可能会导致 AXIs 总线 STALL 掉。并同时给出了三种规避措施。 其中第一种是将 FSIZE 定义得比实际大,以留有足够的裕量。 于是让客户修改代码: 在 QSPI 初始化时将 size 设置成大一倍: 上面红色部分表示的 nor flash 设置成实际的两倍大小。 同时考虑到此处定义了实际两倍大小的 FLASH,多出来的另外一半实际是不存在的,为了避免 CPU 意外访问这个实际不存在的区域,使用 MPU“告诉”CPU 这多出来的一半区间是不可访问的。 于是 MPU 按如下来配置: ![]() 客户再次测试,结果问题不再重现。 为了进一步验证问题,客户尝试按原先的代码直接读取 NOR FLASH 的最后一个字节,结果问题也会重现,再次验证此方法的有效性,至此问题解决。 完整版请查看:附件 ![]() |
【经验分享】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
【2025·STM32峰会】GUI解决方案实训分享1-对LVGL咖啡机例程的牛刀小试以及问题排查
实战经验 | 关于STM32H7使用LL库生成ADC代码工作异常问题说明