引言
因为对能够支持新功能和复杂功能的应用需求不断上升,对配备更大闪存区的设备的需求也在增加。
使用外部闪存可以提供具有近似性能水平的更高存储能力,同时为增加闪存区的需求提供一种经济划算的解决方案。
这样,基于STM32F7x0 超值系列和 STM32H750 超值系列开发的设备能够以更小的内部闪存区来应对市场需求。
本文详细描述了在基于STM32超值系列开发的设备上,从外部存储器执行代码构建应用程序所需的步骤,并讲解了如何从内部闪存启动,然后跳转到片外存储器的用户程序去执行。
1、概述
本文档适用于基于 Arm®的器件。
提示:Arm 是 Arm Limited(或其子公司)在美国和/或其他地区的注册商标。
2、外部存储器代码执行概述
2.1 外部存储器代码执行原则
STM32CubeF7 v1.12.0和STM32CubeH7 v1.3.0固件包提供多个应用程序,用于演示如何从内部闪存启动以及如何配置外部存储器并跳转到用户应用程序(位于外部存储器上)。其中有两个用例,XiP和BootROM,可用于外部存储器代码执行。
XiP 用例旨在从外部闪存(QSPI 或 FMC-NOR 闪存)“芯片内执行”。用户应用程序代码应链接到目标执行存储器地址(外部 QSPI 或 FMC-NOR 闪存)。
BootROM用例旨在演示如何从内部闪存启动,配置外部RAM存储器(SDRAM 或 SRAM),将用户应用程序二进制文件从代码存储区域(SDCARD 或 SPI-Flash 存储器)复制到外部 SDRAM 或外部SRAM,然后跳转到用户应用程序。用户应用程序代码应链接到目标执行存储器地址(外部 SDRAM 或 SRAM)。
下表中所述的应用程序可在固件包中的ApplicationsExtMem_CodeExecution 路径下获得,供下列板使用:
STM32F723E-Discovery板针对STM32F730 器件
STM32F756G_EVAL板针对STM32F750 器件
STM32H743I_EVAL板针对STM32H750 器件
▲表 1. 应用详情
外部存储器启动应用程序负责初始化所需资源,以使外部存储器随时可用。该应用程序根据用户配置初始化所需资源(参见 第 3.3 节配置)。
外部存储器启动应用程序必须设置主堆栈指针,并将应用程序配置为在外部存储器上执行。该类型启动方案支持大小可调的用户应用程序。
外部存储器启动应用程序确保在跳到用户应用程序之前重置或释放安装阶段之后不再需要的任何资源。下图展示了该启动方案:
▲ 图 1. 外部存储器代码启动方案
2.2 外部存储器启动应用程序描述
外部存储器启动应用程序包含STM32CubeF7/H7包上的一组源文件,这些定制的源文件可以匹配每个硬件平台支持的配置。
下图显示了所有受支持配置的所有文件超集示例。
▲ 图 2. 外部存储器启动应用程序源文件超集
3、支持的启动模型
该应用程序支持两种执行方式:
支持芯片内执行(支持 XiP)
支持 BootROM
用户必须通过修改 memory.h 头文件来选择匹配需求的配置。
3.1 支持芯片内执行(XiP)
XiP 模型基于直接从用于代码存储的外部非易失性存储器执行代码。该执行模型需要内存映射支持,以允许 CPU 直接访问代码以执行用户应用程序。XiP 模型可通过 FMC/QSPI 接口在外部 NOR/QSPI 闪存上使用。
外部存储器启动应用程序基于 memory.h 文件中的用户配置对下列易失存储器之一进行配置:SDRAM、SRAM、 PSRAM 或内部 SRAM。在该模型中,易失性存储器仅用于数据访问。
下面的流程图说明了 XiP 模型的操作流程。
▲ 图 3. XiP 模型操作流程
3.2 支持 BootROM BootROM
模型基于从选定的易失性存储器中执行代码。当二进制数据存储在非内存映射模式的存储器(比如 SDCARD)中时,该执行模型非常适合。当二进制数据存储在低吞吐量的存储器(比如 SPI-NOR(使用单线 QSPI 进行仿真))中时,此模型也适用。
外部存储器启动应用程序基于 memory.h 文件中的用户配置对下列其中两个易失存储器进行配置:SDRAM、 SRAM、PSRAM 或内部 SRAM。在该模型中,二进制数据从一个非易失性存储器复制到一个易失性存储器,然后 由外部存储器启动应用程序执行。第二个易失性存储器用于数据。
下面的流程图说明了 BootROM 模型的操作流程。
▲ 图 4. BootROM 模型操作流程
3.3 配置
用户配置由以下定义确定:
DATA_AREA:用于指定用于数据存储的易失性存储器。支持的存储器(取决于所用的板)有:
USE_EXTERNAL_SDRAM:外部SDRAM用于数据存储
USE_EXTERNAL_SRAM:外部SRAM用于数据存储
USE_EXTERNAL_PSRAM:外部PSRAM用于数据存储
USE_INTERNAL_SRAM:内部SRAM用于数据存储
CODE_AREA:用于指定用户应用程序的执行位置。该区域可以是用于BootROM 方案的易失性存储器,也可以是用于XiP方案的非易失性存储器。支持的存储器(取决于所用的硬件)有:
XiP 模型:BINARY_AREA 必须是未定义的:
USE_QSPI:QSPI Flash 用于代码执行
USE_NOR:FMC-NOR Flash 用于代码执行
BootROM 模型:BINARY_AREA 必须已定义
USE_EXTERNAL_SDRAM:外部SDRAM 用于代码执行
USE_EXTERNAL_SRAM:外部SRAM 用于代码执行
USE_EXTERNAL_PSRAM:外部PSRAM 用于代码执行
USE_INTERNAL_SRAM:内部SRAM 用于代码执行
BINARY_AREA:仅在 BootROM模型中定义。它用于指定包含用户应用程序的二进制文件位置。根据所选配置,需要附加定义。支持的存储器(取决于所用的硬件)有:
USE_SPI_NOR:SPI NOR Flash 用于二进制存储
BINARY_BASE_OFFSET:SPI NOR Flash中的二进制偏移
BINARY_SIZE:二进制图像大小
USE_SDCARD:SDCard 用于二进制存储
BINARY_FILENAME:要执行的二进制文件名称
用户应确保所选存储器包含代码和数据,以至少覆盖一个适当的用户应用程序启动。然后,用户应用程序可以初始化所需的任何其他存储器。
3.4 外部存储器部件总结
下表总结了与所用板和启动模型对应的外部存储器部件编号。由于 STM32F7x0 超值系列和 STM32H750 超值系列器件没有专用板,使用的板(与兼容器件)为:
STM32F723E-Discovery 用于模拟 STM32F730 器件。
STM32F756G_EVAL 用于模拟 STM32F750 器件。
STM32H743I_EVAL 用于模拟 STM32H750 器件。
▲ 表 2. 启动模型在每个板上使用的外部存储器
4、需要考虑的资源约束
初始化后,不再需要的任何资源(中断、正在进行的传输、未使用的引脚)都应在跳到用户应用程序之前释放。必须这样做以避免额外的功耗,并限制对用户应用程序的任何干扰。特别是对于BootROM 模型,由于不再需要用于二进制存储的外设,因此应将其重置。
用户应考虑外部存储器启动应用程序使用的资源数量,以确保外部存储器接口保持正常运行。资源约束与以下因素有关:
引脚分配和配置
接口配置(不应修改 QSPI IP 寄存器,FMC IP 寄存器即使是部分更新)
配置 RCC,以避免 IP 重置时钟,禁用和以有害的方式更新时钟频率/源。
下面的引脚分配表作为参考,实际中根据使用的板进行引脚选择是必须的。可根据可用的替代功能选择使用其他引 脚。
▲ 表 3. 板为每个存储器分配的引脚
下表总结了应保持不变的资源。它列出了不应修改的外设(或外设的一部分),以避免外部存储不可用。不应重置 上述外设或禁用时钟,也不应以可能改变其行为的方式进行重新配置。
提示 部分要素可能会根据为所选板选择的外部存储器启动应用程序配置和平台硬件而更改。
▲ 表 4. 内存类型所需的外设
5、外部存储器用户应用程序描述
5.1 需要的更新
外部存储器应用程序基于特定的启动方案,该方案与标准的启动方案不同,支持从片上应用到片外应用的平稳过渡。
当应用程序的位置发生变化时,用户必须进行两项更新:
确保使用所需的链接器文件,并提供与所选启动选项相对应的内存映射。
更新 VTOR 设置,以使用正确的地址。
5.2 加载和调试
STM32F723E-Discovery、STM32756G_EVAL和STM32H743I_EVAL这三种板都有面向外部非易失性内存的加载器。这些加载器在STM32CubeF7/H7中以如下形式提供:
EWARM IDE 的补丁
MDK-ARM IDE 的专用包
XiP 模型提供了类似于内部 Flash 调试的无缝加载和调试体验。对于 SW4STM32 IDE,应使用 STM32CubeProgrammer 在外部闪存上加载应用程序。
在 BootROM 模型中,应用程序被编译和链接,以便从外部易失性内存执行:
External SDRAM:链接器地址 0xD0000000 用于 STM32H750 超值系列,而 0xC0000000 用于 STM32F7x0 超值系列
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. STM32CubeProgrammer
5.3 使用 EWARM IDE 进行调试
在调试从外部存储器运行的用户应用程序时,需要特别注意EWARM IDE。EWARM 将 PC(程序计数器)的默认CPU 重置值覆盖为用户应用程序中给定的值(外部执行存储器中的地址值)。
在该启动方案中,在执行外部存储器启动应用程序之前,用户应用程序 PC 地址保持不可访问(因此外部存储器已经准备好,并通过FMC 或 QSPI 映射内存)。如果 EWARM 直接跳到用户应用程序的起始点,就会生成hardfault。为了避免 hardfault,用户应在调试器选项中添加“--drv_reset_to_cpu_start”命令行,如下图所示。此设置防止EWARM强制PC,并让外部存储器启动应用程序在跳到用户应用程序之前配置外部存储器。
▲ 图 6. 调试器命令行选项
6、性能特性
当从外部存储器执行时,由于外部闪存延迟和较长的指令/数据路径,性能会受到影响。如果使用STM32F7x0超值系列和STM32H750超值系列设备,Cortex-M7 L1-cache可以减少这种影响。
下表总结了每个 ROM / RAM 组合取得的 EEMBC® CoreMark®分数。当从内部闪存执行时,可以获得最佳性能。然而,当从外部存储器执行时,损失会显著减少。
这些数字说明了从外部存储器进行操作时对CPU性能的影响。提供内部 Flash 配置分数作为参考。
▲ 表 5. 每种配置的 EEMBC® CoreMark®分数