关键词：死机， 外扩 FLASH
目录预览
1. 问题现象
2. 问题分析及测试
3. 后记
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 按如下来配置：
使用串口终端工具，分别连接 USART1，USART3，发送对应的 UART Bootloader 命令，得到下图 3 的命令交互。
图3. MPU 配置
客户再次测试，问题不再重现。为了进一步验证问题，客户尝试按原先的代码直接读取 NOR FLASH 的最后一个字节，问题还会重现，再次验证此方法的有效性，至此问题解决。
3.后记
有些人可能会问，NOR FLASH 的最后一个字节 CPU 真的会去访问吗 ? 客户的程序占满了整个 FLASH 空间了吗 ? 若那个地址没有代码那还会不会有这个问题。
其实勘误手册 2.4.4 节也提到了，不管 FSIZE 定义的空间最后的一个字节内容是什么，均会有此问题。那么 CPU 为什么会去访问此地址呢 ? 其实这是 M7 内核的指令预取和分支预测试探性访问导致的。
在 M7 编程手册中可以找到如下内容：
正是上述特性才导致 CPU 会提前访问 NOR FLASH 上的地址，即使当前 PC 指针还未指到那里。我们可以通过合适的MPU配置防止因试探性访问外存而导致问题。
长按扫码关注公众号
更多资讯，尽在STM32
▽点击“阅读原文”，可下载原文档
