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配置防止因试探性访问外存而导致问题。

参考文献：

1. PM0235:STM32F7 Series and STM32H7 Series Cortex®-M7 processor programming manua.

2. ES0396:STM32H750xB and STM32H753xI device limitations.

3. AN4838:Managing memory protection unit in STM32 MCUs.

4. AN4893:Level 1 cache on STM32F7 Series and STM32H7 Series.

我们言简意赅的普及下这个知识点，争取让大家不伤脑细胞。

背景知识

M3，M4内核芯片上电复位后，要固定从0x0000 0000地址读取中断向量表，获取复位中断服务程序的入口地址后，进入复位中断服务程序，其中0x0000 0004存的是复位中断服务程序地址。

引出问题

既然ARM规定了M3，M4内核要从地址0x0000 0000读取中断向量表，而STM32设置Flash地址到0x0800 0000怎么办？

STM32支持了个内存重映射功能，将地址0x0800 0000开始的内容重映射到首地址0x0000 0000中，这样就解决了从0x0000 0000读取中断向量表的问题。
那么新的问题来：

（1） 你怎么保证0x08000 0000首地址存的就是中断向量表，我们不可以随意设置吗？

保证中断向量表存到0x0800 0000，这个涉及到分散加载的一个小知识，以MDK为例，如果大家看xxx.S启动文件，里面通过AREA定义了一个名叫RESET的段，这段存的就是中断向量表。

这个名字很重要，MDK对应的xxx.sct分散加载里面通过下面这句将这个RESET段放在了0x0800 0000优先存储。

这样我们就解决了0x0800 0000首地址存储中断向量表，一旦程序开始运行后，我们就可以随意设置中断向量表的位置了。比如想将中断向量表存到内部SRAM，我们就可以操作寄存器SCB->VTOR 重新安排，然后将0x0800 0000的内容复制到设置的地址内即可。

（2） 既然设置到0x0800 0000这么麻烦，为什么不直接使用0x0000 0000？

这是因为STM32不仅可以从内部Flash启动，还可以从系统存储器（可以实现串口ISP，USB DFU等程序下载方式）和从内部SRAM启动，

我们将内部Flash安排到0x0000 0000显然是不行的。这样会导致系统存储器或者内部SRAM无法重映射到0x0000 0000了。

了解了M3和M4，使用M7是怎么个执行情况呢？

M7内核芯片比较灵活了，改变了固定从0x0000 0000地址读取中断向量表的问题，以STM32H7为例，可以从 0x0000 0000 到 0x3FFF 0000 所有地址进行启动。

专门安排了个选项字节来配置。

引言

因为对能够支持新功能和复杂功能的应用需求不断上升，对配备更大闪存区的设备的需求也在增加。

使用外部闪存可以提供具有近似性能水平的更高存储能力，同时为增加闪存区的需求提供一种经济划算的解决方案。

这样，基于STM32F7x0 超值系列和 STM32H750 超值系列开发的设备能够以更小的内部闪存区来应对市场需求。

本文详细描述了在基于STM32超值系列开发的设备上，从外部存储器执行代码构建应用程序所需的步骤，并讲解了如何从内部闪存启动，然后跳转到片外存储器的用户程序去执行。

1 概述

本文档适用于基于 Arm®的器件。

提示：Arm 是 ArmLimited（或其子公司）在美国和/或其他地区的注册商标。

2 外部存储器代码执行概述

2.1 外部存储器代码执行原则

STM32CubeF7 v1.12.0和STM32CubeH7 v1.3.0固件包提供多个应用程序，用于演示如何从内部闪存启动以及如何配置外部存储器并跳转到用户应用程序（位于外部存储器上）。其中有两个用例，XiP和BootROM，可用于外部存储器代码执行。

(1) XiP 用例旨在从外部闪存（QSPI 或 FMC-NOR 闪存）“芯片内执行”。用户应用程序代码应链接到目标执行存储器地址（外部 QSPI 或 FMC-NOR 闪存）。

(2) BootROM用例旨在演示如何从内部闪存启动，配置外部RAM存储器（SDRAM 或 SRAM），将用户应用程序二进制文件从代码存储区域（SDCARD 或 SPI-Flash 存储器）复制到外部 SDRAM 或外部SRAM，然后跳转到用户应用程序。用户应用程序代码应链接到目标执行存储器地址（外部 SDRAM 或 SRAM）。

下表中所述的应用程序可在固件包中的\Applications\ExtMem_CodeExecution路径下获得，供下列板使用：

(1) STM32F723E-Discovery板针对STM32F730 器件
(2) STM32F756G_EVAL板针对STM32F750 器件
(3) STM32H743I_EVAL板针对STM32H750 器件

外部存储器启动应用程序负责初始化所需资源，以使外部存储器随时可用。该应用程序根据用户配置初始化所需资源（参见 第 3.3 节配置）。

外部存储器启动应用程序必须设置主堆栈指针，并将应用程序配置为在外部存储器上执行。该类型启动方案支持大小可调的用户应用程序。

外部存储器启动应用程序确保在跳到用户应用程序之前重置或释放安装阶段之后不再需要的任何资源。下图展示了该启动方案：

2.2 外部存储器启动应用程序描述

外部存储器启动应用程序包含STM32CubeF7/H7包上的一组源文件，这些定制的源文件可以匹配每个硬件平台支持的配置。

下图显示了所有受支持配置的所有文件超集示例。

3 支持的启动模型

该应用程序支持两种执行方式：

(1) 支持芯片内执行（支持 XiP）
(2) 支持 BootROM

用户必须通过修改 memory.h 头文件来选择匹配需求的配置。

3.1 支持芯片内执行（XiP）

XiP 模型基于直接从用于代码存储的外部非易失性存储器执行代码。该执行模型需要内存映射支持，以允许 CPU 直接访问代码以执行用户应用程序。XiP 模型可通过 FMC/QSPI 接口在外部 NOR/QSPI 闪存上使用。

外部存储器启动应用程序基于 memory.h 文件中的用户配置对下列易失存储器之一进行配置：SDRAM、SRAM、 PSRAM 或内部 SRAM。在该模型中，易失性存储器仅用于数据访问。

下面的流程图说明了 XiP 模型的操作流程。

3.2 支持 BootROM BootROM

模型基于从选定的易失性存储器中执行代码。当二进制数据存储在非内存映射模式的存储器（比如SDCARD）中时，该执行模型非常适合。当二进制数据存储在低吞吐量的存储器（比如 SPI-NOR（使用单线 QSPI 进行仿真））中时，此模型也适用。

外部存储器启动应用程序基于 memory.h 文件中的用户配置对下列其中两个易失存储器进行配置：SDRAM、 SRAM、PSRAM 或内部 SRAM。在该模型中，二进制数据从一个非易失性存储器复制到一个易失性存储器，然后 由外部存储器启动应用程序执行。第二个易失性存储器用于数据。
下面的流程图说明了 BootROM 模型的操作流程。

3.3 配置

用户配置由以下定义确定：

DATA_AREA：用于指定用于数据存储的易失性存储器。支持的存储器（取决于所用的板）有：

(1) USE_EXTERNAL_SDRAM：外部SDRAM用于数据存储
(2) USE_EXTERNAL_SRAM：外部SRAM用于数据存储
(3) USE_EXTERNAL_PSRAM：外部PSRAM用于数据存储
(4) USE_INTERNAL_SRAM：内部SRAM用于数据存储

CODE_AREA：用于指定用户应用程序的执行位置。该区域可以是用于BootROM 方案的易失性存储器，也可以是用于XiP方案的非易失性存储器。支持的存储器（取决于所用的硬件）有：

(1) XiP 模型：BINARY_AREA必须是未定义的：

1) USE_QSPI：QSPI Flash 用于代码执行
2) USE_NOR：FMC-NOR Flash 用于代码执行

(2) BootROM 模型：BINARY_AREA 必须已定义

1) USE_EXTERNAL_SDRAM：外部SDRAM 用于代码执行
2) USE_EXTERNAL_SRAM：外部SRAM 用于代码执行
3) USE_EXTERNAL_PSRAM：外部PSRAM 用于代码执行
4) USE_INTERNAL_SRAM：内部SRAM 用于代码执行
BINARY_AREA：仅在 BootROM模型中定义。它用于指定包含用户应用程序的二进制文件位置。根据所选配置，需要附加定义。支持的存储器（取决于所用的硬件）有：

(1) USE_SPI_NOR：SPI NOR Flash 用于二进制存储

1) BINARY_BASE_OFFSET：SPI NOR Flash中的二进制偏移
2) BINARY_SIZE：二进制图像大小

(2) USE_SDCARD：SDCard 用于二进制存储

BINARY_FILENAME：要执行的二进制文件名称

用户应确保所选存储器包含代码和数据，以至少覆盖一个适当的用户应用程序启动。然后，用户应用程序可以初始化所需的任何其他存储器。

3.4 外部存储器部件总结

下表总结了与所用板和启动模型对应的外部存储器部件编号。由于 STM32F7x0 超值系列和TM32H750 超值系列器件没有专用板，使用的板（与兼容器件）为：

(1) STM32F723E-Discovery 用于模拟 STM32F730 器件。
(2) STM32F756G_EVAL 用于模拟 STM32F750 器件。
(3) STM32H743I_EVAL 用于模拟 STM32H750 器件。

4 需要考虑的资源约束

初始化后，不再需要的任何资源（中断、正在进行的传输、未使用的引脚）都应在跳到用户应用程序之前释放。必须这样做以避免额外的功耗，并限制对用户应用程序的任何干扰。特别是对于BootROM 模型，由于不再需要用于二进制存储的外设，因此应将其重置。

用户应考虑外部存储器启动应用程序使用的资源数量，以确保外部存储器接口保持正常运行。资源约束与以下因素有关：

(1) 引脚分配和配置
(2) 接口配置（不应修改 QSPI IP 寄存器，FMC IP 寄存器即使是部分更新）
(3) 配置 RCC，以避免 IP 重置时钟，禁用和以有害的方式更新时钟频率/源。

下面的引脚分配表作为参考，实际中根据使用的板进行引脚选择是必须的。可根据可用的替代功能选择使用其他引 脚。

下表总结了应保持不变的资源。它列出了不应修改的外设（或外设的一部分），以避免外部存储不可用。不应重置 上述外设或禁用时钟，也不应以可能改变其行为的方式进行重新配置。

提示 部分要素可能会根据为所选板选择的外部存储器启动应用程序配置和平台硬件而更改。

5 外部存储器用户应用程序描述

5.1 需要的更新

外部存储器应用程序基于特定的启动方案，该方案与标准的启动方案不同，支持从片上应用到片外应用的平稳过渡。

当应用程序的位置发生变化时，用户必须进行两项更新：

(1) 确保使用所需的链接器文件，并提供与所选启动选项相对应的内存映射。
(2) 更新 VTOR 设置，以使用正确的地址。

5.2 加载和调试

STM32F723E-Discovery、STM32756G_EVAL和STM32H743I_EVAL这三种板都有面向外部非易失性内存的加载器。这些加载器在STM32CubeF7/H7中以如下形式提供：

(1) EWARM IDE 的补丁
(2) MDK-ARM IDE 的专用包

XiP 模型提供了类似于内部Flash 调试的无缝加载和调试体验。对于 SW4STM32 IDE，应使用STM32CubeProgrammer 在外部闪存上加载应用程序。

在 BootROM 模型中，应用程序被编译和链接，以便从外部易失性内存执行：

(1) External SDRAM：链接器地址 0xD0000000 用于 STM32H750 超值系列，而 0xC0000000 用于 STM32F7x0 超值系列

(2) External SRAM：链接器地址 0x68000000 用于 STM32H750 超值系列和 STM32F7x0 超值系列

然后将应用程序二进制文件存储到 SPI_NOR 闪存或 SDCARD 中。由启动应用程序将用户应用程序从存储区域复 制到执行 RAM 区域。

因此，应用程序的加载模式不能由 IDE（MDK-ARM 或 EWARM）外部存储Flash 加载器处理（因为应用程序的链 接地址和存储地址不同）。

根据 BINARY_AREA 定义（在启动应用程序的 “memory.h” 文件中指定），该模型需要使用以下两种不同的加载模式：

SPI_NOR

用户应用程序应存储在地址为0x90000000的SPI-NOR闪存中。必须使用 STM32CubeProgrammer 来完成。应用程序的输出应为二进制格式，以便能够指定一个不同的加载地址，即 SPI-Flash 地址。详细信息请参见下图。

SDCARD

用户应手动将二进制文件（构建的输出）复制到用于存储用户应用程序的 SDCARD 中，然后将 SDCARD 插入评估板。

下图显示了加载和调试的步骤：

5.3 使用 EWARM IDE 进行调试

在调试从外部存储器运行的用户应用程序时，需要特别注意EWARM IDE。EWARM 将 PC（程序计数器）的默认CPU重置值覆盖为用户应用程序中给定的值（外部执行存储器中的地址值）。

在该启动方案中，在执行外部存储器启动应用程序之前，用户应用程序 PC 地址保持不可访问（因此外部存储器已经准备好，并通过FMC 或 QSPI 映射内存）。如果EWARM 直接跳到用户应用程序的起始点，就会生成hardfault。为了避免 hardfault，用户应在调试器选项中添加“---drv_reset_to_cpu_start”命令行，如下图所示。此设置防止EWARM强制PC，并让外部存储器启动应用程序在跳到用户应用程序之前配置外部存储器。

6 性能特性

当从外部存储器执行时，由于外部闪存延迟和较长的指令/数据路径，性能会受到影响。如果使用STM32F7x0超值系列和STM32H750超值系列设备，Cortex-M7 L1-cache可以减少这种影响。

下表总结了每个 ROM / RAM 组合取得的 EEMBC® CoreMark®分数。当从内部闪存执行时，可以获得最佳性能。然而，当从外部存储器执行时，损失会显著减少。

这些数字说明了从外部存储器进行操作时对CPU性能的影响。提供内部 Flash 配置分数作为参考。