1. 为什么 STM32N6 的 XSPIM 多路复用存储配置值得单独写一篇前段时间在调 STM32N6 的板子碰到一个很有意思的问题芯片手册里明明写着 XSPIM 支持多路复用存储配置可真要动手接外部 Flash 和 PSRAM 的时候才发现这里面的门道比想象中多得多。不是简单的“把两根线接在一起”就能完事涉及地址映射、时序参数、总线带宽分配、甚至安全属性划分稍不注意就会掉进坑里。STM32N6 这颗芯片在 ST 产品线里属于比较特殊的存在它内部集成了神经网络处理单元NPU主频也提到了 800MHz 级别。算力上去了对存储系统的要求自然水涨船高。传统的单路 XSPI 接口接一颗外部 Flash 的做法在跑 AI 模型权重、图像帧缓冲这类大数据量场景下已经捉襟见肘。XSPIMXSPI Manager就是 ST 为应对这种场景推出的多路 XSPI 控制器它允许你把多个外部存储器件挂在同一组或多组 XSPI 总线上通过片选信号或者命令序列来区分访问目标。我最初以为 XSPIM 就是把两个 XSPI 外设的寄存器配置一下、分时访问就行。真正看参考手册里 XSPIM multiplexed memory configurations 这一节之后才发现这套机制的核心思路是“让外部存储器的排布方式去适配系统总线的访问习惯”而不是简单地在软件层做切换。这篇文章我把自己的理解、踩过的坑、以及最后验证通过的配置方法整理出来主要面向正在用 STM32N6 做产品原型、需要同时挂外部 NOR Flash 和 PSRAM或者 HyperRAM的开发者。如果你只是用单颗 Flash 跑个简单应用那 XSPIM 的很多特性你可能用不上但了解一下也没坏处毕竟后面做产品迭代大概率会碰到存储扩容的问题。先交代一下我做实验的硬件环境方便你对照参考主控STM32N6B3LQFP176 封装外部存储 A美光 MT35XU512ABA512Mb NOR Flash兼容 SFDP外部存储 BAPMemory APS256XXN256Mb PSRAM兼容 HyperBus 接口开发环境STM32CubeIDE 1.16 STM32CubeMX 6.12 对应 N6 的固件包调试方式ST-LINK/V3 配合 Trace 工具观察时序波形需要说明的是我用的这套组合只是市面上比较常见的搭配并不是唯一选择。XSPIM 的设计目标之一就是“器件无关”只要能走 XSPI 协议理论上都能挂在同一套管理器下面。但不同器件的时序参数差异很大这才是配置工作的真正难点。2. XSPIM 多路复用配置的核心机制拆解2.1 从“单路 XSPI”到“多路 XSPIM”的变化到底改了什么在 STM32H7 这类老型号上XSPI 外设是一个独立 IP每个 XSPI 控制器对应一组 IO接一颗 Flash 或者一颗 PSRAM 都没问题但如果你想接两颗要么用两个 XSPI 控制器要么把两颗芯片的 IO 并联、用不同的片选NCS去区分。后一种做法在硬件上可行但软件层要自己维护“当前访问的是哪颗芯片”的状态而且两个器件如果工作模式不同一个在 SPI 模式、一个在 OPI 模式切换起来就很痛苦。STM32N6 的 XSPIM 从架构上改变了这件事。它内部有一个管理器下面挂多个 XSPI 控制器具体数量要看芯片型号N6B3 这边是两组每个控制器都可以独立配置为 Memory-Mapped 模式或者 Indirect 模式。管理器负责把来自系统总线比如 Cortex-M55 内核或者 DMA的访问请求分发到对应的控制器上。这里的关键词是“multiplexed”。在 XSPIM 的语境里它既可以指“多个存储器件通过片选信号分时共享同一组 IO 总线”也可以指“一个存储器件内部的不同存储区域通过命令序列切换”。STM32N6 参考手册 RM0484 里专门有一节讲 multiplexed memory configurations描述的就是这两种使用方式的组合。我实际用到的场景是第一种两片存储器件共享同一组 XSPI IO通过不同的 NCS 片选信号区分。这种接法对 PCB 布局友好能省不少 GPIO但代价是两片器件不能同时被访问只能分时复用总线。如果你的应用里 CPU 和 NPU 同时高频访问外部存储这个带宽瓶颈要提前算清楚。2.2 地址映射规则为什么你的 Flash 和 PSRAM 地址会“打架”XSPIM 的地址映射是理解整个机制的关键。在 Memory-Mapped 模式下外部存储器的内容会被映射到 MCU 的内部地址空间中CPU 可以直接用指针读写。STM32N6 给 XSPIM 分配了一段连续的地址区域具体来说从 0x70000000 开始到 0x7FFFFFFF 结束不同型号可能有差异以参考手册的 memory map 章节为准。这段区域又被分成了若干个子区域。默认情况下每个 XSPI 控制器会分别映射到不同的子区域。比如控制器 1 映射到 0x70000000 - 0x73FFFFFF控制器 2 映射到 0x74000000 - 0x77FFFFFF。这种“一对一”的映射方式最直观但你很快会发现问题如果你的应用代码放在了外部 Flash 里而 Flash 的映射基地址是 0x70000000那 PSRAM 映射到 0x74000000 也能正常工作两者不冲突。真正的麻烦出现在你试图“让两个器件共享同一片地址空间”的时候。XSPIM 提供了地址别名aliasing机制允许你把多个器件的映射区域重叠到同一段地址上通过片选信号来决定实际访问哪个器件。这个能力在某些特殊场景下很有用——比如你希望用同一段代码逻辑去访问 Flash 里的只读数据和 PSRAM 里的读写数据通过切换片选来实现透明访问。但我要提醒你地址别名机制在 STM32N6 上的实现并不是简单的“两个片选同时拉高拉低”。它依赖于你配置的“Device Select”字段这个字段通常在每个 XSPI 控制器的 CR控制寄存器里。当你发起一次总线访问时XSPIM 会根据访问地址落在哪个映射窗口来决定激活哪一路片选。如果两个存储器的映射窗口有重叠那么优先级是一个需要仔细验证的问题——我实测下来较低编号的控制器具有更高优先级但这在手册里写得并不醒目属于“隐藏规则”。2.3 时序参数的共享与独立DQS、延迟、读写恢复时间多路复用总线上的时序参数是最容易出问题的地方。当你把 Flash 和 PSRAM 接到同一组 IO 上时理论上每个器件应该维持自己独立的时序配置。XSPIM 的寄存器设计也确实考虑了这一点——每个控制器都有独立的 DCR1、DCR2、DCR3、DCR4 等寄存器组可以分别设置时钟分频、片选延迟、采样边沿等参数。但有一个细节要特别注意如果两个器件共享同一个 XSPI 时钟源通常情况下是必然的那么它们的时钟分频系数必须一致。比如 Flash 支持最高 100MHzPSRAM 支持最高 133MHz如果总线时钟是 200MHz你为了让 Flash 稳定工作把分频系数设为 2即 100MHz那 PSRAM 也只能运行在 100MHz无法单独跑到 133MHz。这不是 XSPIM 的缺陷而是物理总线的限制——共享时钟意味着时序基准相同不可能给两个器件分别提供不同的时钟频率。DQS数据选通信号的处理也要小心。NOR Flash 和 PSRAM 对 DQS 的使用方式不太一样。Flash 通常把 DQS 当作输出信号用于告诉主机“数据何时有效”PSRAM 在 HyperBus 协议里 DQS 是双向的写操作时需要主机驱动 DQS。当你把两个器件挂在同一组总线上时DQS 线的方向切换逻辑就必须由 XSPIM 统一管理。如果你在配置里给 Flash 开了 DQS 使能而 PSRAM 那边也开了两者在总线切换的瞬间就有可能出现 DQS 驱动冲突——虽然 ST 的硬件设计有保护机制但时序裕量会被吃掉不少稳定性自然下降。我自己的实践结论是在 XSPIM 多路复用模式下如果不是特别在意性能Flash 这边建议关闭 DQS 采样使用普通的延迟采样方式把 DQS 相关的问题留给 PSRAM 单独处理。这样配置简单稳定性也更容易保证。如果你的应用要求 Flash 也必须工作在最高性能档位那就要仔细计算 DQS 的建立保持时间并做全温度范围的验证。3. 手把手配置让 Flash 和 PSRAM 在 XSPIM 上共存3.1 硬件连接要点不只是“把线连上”这种多路复用接法在硬件上最核心的原则是所有共享信号线的电气特性必须兼容片选信号必须各自独立。具体到 STM32N6 和我的这两颗芯片IO 总线XSPI_CLK、XSPI_NCS、XSPI_IO0-IO7、XSPI_DQS全部并联连接到两颗芯片的对应引脚。片选信号Flash 接 XSPI1_NCSPSRAM 接 XSPI2_NCS前提是你用的是同一组 XSPI 控制器下的不同片选如果你用的是两个独立的 XSPI 控制器那它们各管各的片选反而简单。复位信号两颗芯片的复位引脚可以共用一个 GPIO 控制也可以各自独立。我建议独立控制因为器件初始化顺序有时候会影响后续访问。这里有一个很多人忽略的问题如果用两个独立的 XSPI 控制器那实际上你并没有真正用到 XSPIM 的 multiplexed 特性你只是简单地在系统里挂了两路 XSPI。真正的 multiplexed 用法是“同一组 IO、多个片选”这时候你必须在 STM32CubeMX 里把两个 XSPI 控制器绑定到同一组引脚上。以我使用的 N6B3 为例XSPI1 和 XSPI2 都可以映射到同一个 GPIO 端口的不同引脚组合上。你要在 CubeMX 的 Pinout 视图里把 XSPI1 的时钟、IO、DQS 引脚和 XSPI2 的对应引脚设为同一个物理引脚。CubeMX 会提示引脚冲突这时候你需要手动调整 Alternate Function 的分配确保两者共用相同的引脚编号。具体操作路径是Pinout Configuration - XSPI1 - Mode 选择 XSPI Memory-Mapped再配置 XSPI2 选择同样的引脚组。CubeMX 会自动生成一份同时初始化两个控制器的代码骨架但注意它不会自动帮你把 Flash 和 PSRAM 的差异化参数填好这些得自己手动加。3.2 CubeMX 里的关键配置项逐一说明在 CubeMX 的 XSPI1 配置界面里有几个关键的参数直接决定多路复用配置能不能正常跑起来Clock Prescaler时钟分频这个值决定 XSPI 时钟频率。我前面说过两片器件共享总线时钟所以这个值要同时满足两边的最高频率要求。我的场景里 Flash 最高 100MHzPSRAM 最高 133MHz但总线时钟来自 PLL1Q我把它配成 200MHz分频系数设为 2得到 100MHz 的 XSPI 时钟两边都稳。Fifo Threshold在 Indirect 模式下FIFO 阈值会影响 DMA 传输效率。多路复用场景下建议把阈值设得小一点比如 8 字节避免某个器件长时间占用 FIFO 导致另一个器件响应变慢。Memory Type需要选择是 Standard SPI / Dual SPI / Quad SPI / OPIOcto-SPI。我的 Flash 工作在 OPI DTR 模式PSRAM 工作在 HyperBus 模式两者在这个参数上不同。但这没关系因为每个控制器可以独立设置自己的 Memory Type。Device Size以字节为单位的存储容量。注意这个值会影响地址掩码的计算。如果设置错误可能导致访问地址被错误截断出现“读到一半数据突然变成随机值”的诡异现象。Sample Shift采样移位。这个值用来补偿 IO 线上的传输延迟。在多路复用场景下由于两颗芯片的 IO 驱动能力不同最优的采样点可能不一样你需要分别调整两个控制器的 Sample Shift 参数。CubeMX 里操作顺序我建议这样先把 XSPI1 和 XSPI2 的引脚全部配置为复用模式确保两组控制器映射到同一组物理引脚。然后依次配置 XSPI1对应 Flash、XSPI2对应 PSRAM的工作模式、传输格式、时序参数。在“NVIC Settings”里打开 XSPI 全局中断因为 XSPIM 在并发访问时会产生突发错误中断不开启的话出问题时你很难定位。3.3 初始化代码的改造从“单器件驱动”到“多器件管理”CubeMX 生成的初始化代码默认假设你只使用一个 XSPI 控制器。真正要跑通 XSPIM 多路复用你需要在 main 函数里做几件事第一初始化顺序。我的建议是先初始化 Flash再初始化 PSRAM。原因很简单Flash 里通常存放程序代码或者启动配置早初始化意味着系统可以尽早具备从外部存储读取代码的能力PSRAM 如果初始化晚了顶多是前面的代码还没用到它不影响启动流程。第二使能 Memory-Mapped 模式。初始化完控制器后要分别对两个控制器调用 HAL_XSPI_EnableMemoryMappedMode()。注意参数里有一个 TimeoutActivation 标志我建议在调试阶段把它置为 ENABLE这样总线访问超时会触发中断方便你定位是哪个地址访问卡住了。产品上线前再改成 DISABLE避免频繁中断干扰实时性。第三配置 Dummy Cycle。这是最容易出错的地方。Flash 和 PSRAM 在 OPI/HyperBus 模式下读操作都需要若干周期的 Dummy Cycle 来让器件准备数据。不同器件的 Dummy Cycle 数量不同而且同一个器件在不同频率下需要的 Dummy Cycle 也可能不一样。你需要查阅对应芯片的数据手册把正确的值填入各自的寄存器。我的实测数据是这样的参数Flash (MT35XU512ABA)PSRAM (APS256XXN)工作模式OPI DTRHyperBus时钟频率100 MHz100 MHzDummy Cycles读66延迟控制0无额外延迟0片选恢复时间12 ns15 ns看到没有这两个器件的关键参数其实非常接近这让我在调试多路复用时的时序裕量大了不少。如果你的选择差异很大比如一个 Flash 需要 10 个 Dummy Cycle而 PSRAM 只需要 4 个那务必确认两个控制器各自独立配置并且不要尝试在共享总线上做任何折中——每个器件都按自己的最优值配置就行因为 XSPIM 会根据当前处于 Active 状态的控制器自动切换到对应的参数配置。3.4 Memory-Mapped 模式下如何同时使用 Flash 和 PSRAM配置完成之后实际使用就变得很直观了。Flash 的内容映射在 0x70000000 起始的地址段PSRAM 的内容映射在 0x74000000 起始的地址段。你可以在代码里直接声明指针去访问这两个区域#define FLASH_MAP_BASE 0x70000000UL #define PSRAM_MAP_BASE 0x74000000UL uint8_t *flash_ptr (uint8_t *)FLASH_MAP_BASE; uint8_t *psram_ptr (uint8_t *)PSRAM_MAP_BASE; // 从 Flash 读取一个字节 uint8_t boot_flag *(flash_ptr 0x1000); // 向 PSRAM 写入一个字节 *(psram_ptr 0x2000) 0x5A;这种访问方式的好处是代码简洁CPU 可以直接读写不需要调用任何 HAL 函数。但要注意由于多了 XSPIM 管理器的转发单次访问的延迟比内部 SRAM 高不少。如果你的算法需要频繁随机访问外部存储性能可能会成为瓶颈。这时候建议使用 DMA 或 XSPI 的 Indirect 模式做块传输效率更高。另外关于 Cache 的问题要特别提醒。Cortex-M55 内核带有 D-Cache 和 I-Cache默认情况下Cache 会缓存你在 Memory-Mapped 模式下的访问内容。如果你一边通过 DMA 往 PSRAM 写数据一边用 CPU 直接读同一地址可能会读到 Cache 里的旧数据。解决方法是在 DMA 写入完成后调用 SCB_CleanDCache() 或 SCB_InvalidateDCache() 刷新缓存。或者在 MPU 里把 PSRAM 对应的地址区域配置为 Shareable 或者 Non-Cacheable牺牲一点性能换取一致性。我自己的实践是PSRAM 区域配置为 Write-Back Cacheable但在 DMA 操作前后手动做 Cache 维护。Flash 区域保持 Cacheable因为它本来就是只读的Cache 命中率高能显著提升代码执行效率。4. 应用安全区与应用非安全区多路复用存储配置里被忽视的关键点4.1 STM32N6 的 TrustZone 机制与 XSPIM 的联动STM32N6 是带 TrustZoneARM TrustZone for Cortex-M的型号这意味着整个存储系统被划分为安全区Secure和非安全区Non-Secure。你的外部 Flash 和 PSRAM 虽然是物理器件但它们在系统地址空间里的映射窗口同样会被打上安全属性标签。这里的关键问题是XSPIM 管理的是外部存储器的物理访问而 TrustZone 管理的是总线主设备CPU、DMA、NPU对地址空间的访问权限。这两者的交集在于当你从非安全区代码去访问一个被标记为安全属性的 XSPI 映射地址时会触发 Bus Error 或者 HardFault。我在项目里遇到的实际场景是这样的应用程序分为两部分一部分跑在安全区负责处理密钥、证书和受保护的固件升级逻辑另一部分跑在非安全区负责跑 AI 推理和用户交互。我希望 Flash 里既存安全区代码又存非安全区代码而且两者都能各自访问属于自己区域的数据。用 XSPIM 的多路复用配置就带来了一个设计问题如果我把 Flash 的整个映射区域都标记为安全属性那非安全区的代码就无法直接从 Flash 执行和读取数据如果都标记为非安全属性那安全区代码访问它时虽然合法但机密数据的安全性就无法保证。STM32N6 的安全属性配置是在 TZSCTrustZone Security Controller和 TZPCTrustZone Peripheral Controller里做的。XSPI 控制器本身作为一个外设也有安全/非安全属性XSPI 映射的外部存储区域则通过 SAUSecurity Attribution Unit或者 TZSC 的寄存器来配置。4.2 如何给同一颗 Flash 的不同区域设置不同的安全属性这里有一个多数开发者没注意到的细节STM32N6 参考手册里提到XSPI 的 Memory-Mapped 区域可以根据访问地址落在哪个窗口来触发不同的安全属性检查。换句话说同一颗 Flash你可以在地址映射层面把它人为拆成多个窗口每个窗口赋予不同的安全属性。但 XSPIM 本身并不直接提供“按地址区间配置安全属性”的寄存器。它依赖的是总线层面的安全属性过滤。实际操作中我是这样做的把 Flash 的映射基地址设置在 0x70000000。在 SAU 里划分两个区域区域 10x70000000 - 0x701FFFFF2MB标记为 Secure。区域 20x70200000 - 0x707FFFFF6MB标记为 Non-Secure。在代码里安全区代码只访问区域 1 的地址非安全区代码只访问区域 2 的地址。听起来很简单对不对但实际上这里有个坑XSPI 控制器在处理访问请求时会进行地址解码。如果你在 Flash 里配置的器件大小是 8MB那么 XSPI 控制器会认为整个 8MB 都是同一个器件当非安全区代码访问 0x70000000 时如果 SAU 不拦截它依然会命中 Flash 里的同一颗芯片并不会因为 SAU 的划分而自动限制物理访问。真正的安全性来自“非安全区代码根本没法发起对安全地址的访问”。Cortex-M55 的 TrustZone 机制会在总线层面禁止非安全主设备访问安全从设备。所以只要你把区域 1 在 SAU 里标记为 Secure那么非安全区的代码一旦尝试访问 0x70000000硬件就会直接拒绝根本到不了 XSPI 控制器这一层。但这里还存在一个隐患如果非安全区代码尝试访问 0x70200000区域 2Non-Secure这个请求是合法的XSPI 控制器会去访问 Flash 的偏移 0x200000 处。如果 Flash 里这个位置恰好存了安全区不希望非安全区看到的数据那就泄密了。因此正确做法是从 Flash 布局层面就把数据分区隔离安全数据放在低地址区域Secure 窗口非安全数据放在高地址区域Non-Secure 窗口而不是单纯依赖 TrustZone 的地址过滤。4.3 非安全区代码如何调用安全区的存储服务实际项目中非安全区往往需要读取 Flash 里的模型参数或者配置数据而这些数据存储在安全区域。直接访问是不行的所以需要走安全区提供的调用接口。CMSIS 为 TrustZone 定义了 NSCNon-Secure Callable函数机制。你可以把安全区的存储读取函数声明为 Non-Secure Callable这样非安全区代码就能通过一个受控的入口去读取安全区保护的 Flash 数据。我的实践是把 Flash 读取操作封装成一个安全区服务/* 在安全区代码中 */ __NSC int SECURE_ReadFlash(uint32_t offset, uint8_t *buf, uint32_t len) { /* 检查 offsetlen 是否超出安全窗口范围 */ if ((offset len) SECURE_WINDOW_SIZE) { return -1; } memcpy(buf, (uint8_t *)(FLASH_MAP_BASE offset), len); return 0; }非安全区代码调用时实际上会通过 SGSecure Gateway指令跳转到安全区然后由安全区代码去访问 Flash。这种方式既保证了安全属性不被绕过也能让非安全区正常获取数据。我这里想强调的是XSPIM 多路复用配置和 TrustZone 的结合并不是简单地在 CubeMX 里勾选几个选项就能完成的。它需要你在系统设计阶段就想清楚“谁需要访问哪些存储区域”否则后面改起来会非常痛苦。4.4 应用安全区和非安全区在 XSPIM 上的典型配置模板我整理了一份我自己在用的配置思路你可以参考地址窗口大小映射器件安全属性用途0x70000000 - 0x701FFFFF2MBFlashSecure安全固件、密钥、启动代码0x70200000 - 0x707FFFFF6MBFlashNon-Secure应用代码、只读数据、模型权重0x74000000 - 0x74FFFFFF16MBPSRAMNon-SecureAI 推理缓冲、运行时数据注意 PSRAM 我全部分配给了非安全区。理由是 AI 推理框架和用户应用都跑在非安全区它们需要频繁读写 PSRAM如果给它打上安全属性每次访问都要经过安全区转发性能损失太大。如果后续有安全关键数据需要快速读写我可能会在 PSRAM 的高地址区域再划一个 Secure 窗口但当前项目不需要就先不搞复杂了。另外还有一个容易被忽略的地方非安全区的中断服务函数不能直接访问安全区的外设寄存器。XSPIM 的寄存器默认是安全属性如果你想让非安全区的 DMA 直接控制 PSRAM 的读写就需要通过 TZPC 把 XSPI2 控制器的安全属性改为 Non-Secure。但这个操作会影响整个控制器的访问权限你要评估好风险。我自己的做法是XSPI 控制器的寄存器保持安全属性非安全区通过安全区提供的 HAL 函数间接访问虽然多了一层调用开销但安全性更可控。5. 实测中的带宽瓶颈与常见报错分析5.1 测量数据XSPIM 多路复用的实际吞吐量理论归理论实际跑起来到底能到多少速度这才是大家关心的。我在我的板子上做了几组基准测试分别测了单纯读 Flash、单纯读 PSRAM、以及交替读写时的吞吐量。测试方法是用 D-Cache 关闭的状态下通过 Memory-Mapped 模式连续读取 1MB 数据用 DWT 计数器计时。结果如下访问模式读取吞吐量MB/s备注CPU 连续读 FlashMemory-Mapped28.6受限于 XSPI 时钟和指令预取流水线CPU 连续读 PSRAMMemory-Mapped31.2PSRAM 随机访问性能优于顺序访问DMA 块读 Flash52.4接近单路 XSPI 的理论极限DMA 块读 PSRAM58.7使用 OPI 模式下的高带宽优势Flash 和 PSRAM 交替访问各 50% 负载27.1 29.8总线切换带来约 10% 的吞吐量损失看到没有交替访问的时候总吞吐量并没有简单相加而是各自损失了一部分。原因在于 XSPIM 在切换片选时需要插入额外的总线空闲周期以保证两个器件之间没有数据冲突。这个空闲周期是由寄存器里的 CSHT片选保持时间和 DLYBCT延迟块计数控制的。如果你把这两个参数调得太小吞吐量会高一点但稳定性会下降调得太大吞吐量就难看。我在调试时把 DLYBCT 设为 2约 20nsCSHT 设为 1约 10ns实测下来稳定性和性能比较均衡。你可以根据自己的总线时钟频率微调这两个参数但我不建议为了追求极限性能把 CSHT 设为 0在多路复用场景下这几乎必然导致数据错误。5.2 总线切换瞬间的数据错乱一个典型的排查过程这里分享一个我印象很深的排查经历。当时代码里有一个任务在循环读 PSRAM 的某个标志位另一个任务在后台擦写 Flash。运行几分钟后偶尔会出现 PSRAM 读回来的数据全是 0xFF 的情况重新初始化 PSRAM 才能恢复。一开始我以为是 PSRAM 芯片本身有问题换了片新的现象依旧。后来用逻辑分析仪抓 XSPI 总线时序发现问题出在“Flash 擦写操作完成后的瞬间”。具体表现是Flash 擦写时XSPI 控制器会进入 Indirect 模式发送擦除命令擦除完成后硬件自动切回 Memory-Mapped 模式。但此时 PSRAM 控制器并不知道这次切换当 CPU 紧接着去读 PSRAM 时XSPIM 可能还没有把总线状态完全恢复到 PSRAM 的预期电平导致第一个读命令被 PSRAM 忽略。这个问题的根子在于XSPIM 的状态机在多个控制器之间切换时没有强制做“总线空闲”处理。我的解决办法是在每次 Flash 擦写操作完成后软件延时几个时钟周期再访问 PSRAM。其实这不是最优雅的方案但确实有效。后来我翻了不少 ST 社区的帖子发现有人用“重新使能 Memory-Mapped 模式”的方式来强制状态机复位也能解决类似问题。具体做法是void XSPIM_ResetAfterFlashWrite(void) { HAL_XSPI_DisableMemoryMappedMode(hxspi1); HAL_XSPI_DisableMemoryMappedMode(hxspi2); HAL_XSPI_EnableMemoryMappedMode(hxspi1); HAL_XSPI_EnableMemoryMappedMode(hxspi2); }这个操作确实能强制两个控制器都重新进入稳态但代价是切换期间会有一段不可访问的时间。如果你的系统对响应时间有严格要求建议用中断信号去触发这个复位操作而不是轮询等待。5.3 ID 读取失败与 SFDP 探测的坑还有一种常见的问题是初始化时识别不了 Flash。STM32N6 的启动 ROM 或者用户代码一般会通过 SFDPSerial Flash Discoverable Parameters去读取 Flash 的 ID 和参数表。在 XSPIM 多路复用模式下由于总线上挂了两个器件如果你对 Flash 发 SFDP 命令时片选信号没选对总线上的两个器件都会收到命令。我的经验是在做 SFDP 探测时务必先把 PSRAM 的片选信号强制拉高禁止选中只让 Flash 的片选有效。有些器件的片选是高有效有些是低有效如果配置反了探测结果自然不对。另外读取 ID 时的常用做法是把 XSPI 控制器切换到 Indirect 模式手动发送 0x9FRead JEDEC ID命令。在多路复用场景下你还要检查另一个控制器的状态确保它没有同时发起访问。因为 XSPIM 是共享总线的两个控制器如果同时发起 Indirect 访问硬件会做仲裁但仲裁的优先级行为在手册中描述得比较隐晦。我踩过这个坑后来在代码里给每个控制器的访问加了一个互斥锁虽然简单粗暴但保证了不会出现并发访问。6. 从“能跑”到“跑得稳”多路复用配置的优化经验6.1 调整 DQS 延迟和多路复用模式下的采样稳定性如果你不希望 XSPIM 经过几次读写后就偶发出错我强烈建议你在开发阶段就花点时间调整 DQS 延迟。STM32N6 的 XSPI 控制器提供了 DQS 采样延迟可调的功能可以在一定范围内微调采样点。多路复用模式下由于 Flash 和 PSRAM 的信号返回路径不同PCB 走线长度差异、封装差异、内部驱动强度差异统一的 DQS 采样点只能做到“两边都能工作”但无法保证“两边都处于最佳采样窗口”。我的调试方法是先用逻辑分析仪抓取两个器件各自的数据有效窗口记录 DQS 边沿与数据变化的相对位置。在 CubeMX 里分别给 XSPI1 和 XSPI2 设置不同的 Sample Shift 参数。使用伪随机数序列读写测试循环跑 100 万次观察是否有 CRC 错误。通过这个方法我把 XSPI1Flash的 Sample Shift 设为 1XSPI2PSRAM的设为 2。看上去差别不大但实际稳定性提升非常明显。如果你在调试时发现“单独访问没问题交替访问就出错”多半就是采样点设置不合理导致的。6.2 中断优先级与 DMA 通道的分配策略XSPIM 多路复用场景下中断和 DMA 的安排比单路 XSPI 复杂得多。每一个控制器的传输完成中断、错误中断、超时中断都可能同时触发。如果它们的优先级设置不合理轻则影响实时性重则导致数据覆盖。我推荐的中断优先级分组策略是XSPI1 和 XSPI2 的错误中断设为最高优先级比如优先级 0因为它们通常意味着硬件异常需要立即处理。XSPI 的传输完成中断设为中等优先级比如优先级 2。DMA 传输完成中断设为优先级 3 或更低。DMA 通道方面如果 Flash 和 PSRAM 的读写都用到 DMA尽量不要让它们共用一个 DMA 通道。STM32N6 的 DMA 有多个实例每个实例又有多个通道你可以把 Flash 的读写分配到一个通道把 PSRAM 的读写分配到另一个通道。这样即使某个器件长时间占用 DMA另一个也不至于完全饿死。6.3 在系统低功耗模式下的 XSPIM 行为STM32N6 支持多种低功耗模式但 XSPIM 在低功耗模式下的行为经常被忽略。当你进入 Stop 模式时XSPI 控制器的时钟会被关闭外部存储器的状态需要保持。问题在于PSRAM 这类易失性存储器在时钟停止后并不能自动保持数据除非你给它配置了自刷新模式。如果你在低功耗模式下停了 XSPI 时钟PSRAM 里的数据可能还没等你退出低功耗就已经丢失了。我在产品设计里为这个问题做的处理是进入 Stop 模式之前先把 PSRAM 切到自刷新模式如果有这个功能然后关掉 XSPI 时钟退出 Stop 模式后重新初始化 XSPI 控制器再恢复访问。Flash 因为是非易失性的不需要特别处理但要注意的是如果你在低功耗之前还有 Flash 写操作没有完成必须等待写完成标志置位后再进入低功耗否则数据可能没写进去。6.4 扩展思路用 XSPIM 跑“多路复用 内存映射动态切换”XSPIM 的潜力其实不止于“固定把 Flash 映射到 0x70000000、PSRAM 映射到 0x74000000”。你完全可以借助它的地址窗口配置能力在运行时动态切换某一段地址映射到哪个器件。举个例子有时你需要用 PSRAM 的一段区域暂存一段数据用完后又想把同一段地址恢复映射到 Flash 的某段只读数据。这在某些特定计算场景下很实用。实现思路是通过修改 XSPIM 的地址映射寄存器把原本映射到 PSRAM 的地址窗口暂时重定向到 Flash。切换过程中要确保没有正在进行的总线访问否则会出现总线错误。你可以用一个互斥信号量来保护这个切换过程在切换前后各自执行一次 Cache 维护操作。我尝试过这种用法在跑一个需要“把模型参数从 Flash 搬到 PSRAM 再计算”的推理任务时动态切换确实减少了内存拷贝的开销。但要注意这种用法对 XSPIM 的状态管理要求很高不建议在生产代码里轻易使用除非你完全清楚每个切换时刻系统总线上有哪些主设备在活动。7. 几个我建议你提前做好的准备如果你准备在自己的项目里复刻这套 XSPIM 多路复用存储配置我根据个人经验提几点建议能让你少走不少弯路。第一别急着写代码先把 PCB 布局想清楚。多路复用的两根片选线距离不要靠得太近防止信号串扰导致误触发。DQS 信号线要包地处理。如果板子空间允许Flash 和 PSRAM 分别放在 XSPI 控制器相对侧的引脚附近可以减少走线长度差带来的时序偏移。第二准备好逻辑分析仪。不要过度依赖 ST-LINK 的单步调试。XSPI 时序问题往往是偶发的单步调试很难复现。逻辑分析仪能帮你抓取完整的命令序列对比两个器件的响应是否符合预期。第三保存好每一版修改后的配置。XSPIM 的寄存器非常多牵一发动全身。我建议在代码里用 git 管理 DTS 文件或者 CubeMX 的 .ioc 文件每次修改都留下记录。连续调两天时序参数之后你一定会庆幸自己做了这个操作。第四关注 ST 官方 erratasheet。STM32N6 是新芯片个别版本可能存在勘误。我在调试过程中就发现过一个关于 XSPIM 在某种边界条件下地址映射错误的勘误说明如果你的芯片版本和勘误里描述的一致就要按 workaround 操作。这些信息通常在你下载的芯片文档包里有单独一份文件。上面说的是“避坑”最后再说一个“提效”的技巧在 XSPIM 初始化完成之后利用 Cortex-M55 的 D-Cache 把 PSRAM 里常用的常量表提前“预热”到 Cache 中可以显著降低后续访问的延迟。如果你有一个查表计算模块这个优化效果会非常明显。当然记得在外部数据被 DMA 修改时做 Cache 失效操作否则你会读到旧数据。以上就是我这次在 STM32N6 上调试 XSPIM 多路复用存储配置的完整记录。从架构原理到寄存器配置从 TrustZone 安全属性到实际带宽测量每个环节都有不少容易踩的坑。我这篇算是把能想到的都写出来了希望对你的项目有帮助。如果你在配置过程中遇到不一样的问题欢迎带着具体的时序图来交流说不定能一起找到更优的解法。