这个项目标题其实已经把方案核心说得很清楚了：两块64MB的Octal PSRAM，挂在MCU同一个XSPI口上，通过EXTENDMEM机制映射成128MB可用内存。听起来像是只改个配置就能搞定的事，但实际上把两颗大容量PSRAM稳定跑起来，中间涉及硬件接线、时序参数、内存映射、Cache一致性等一系列问题，任何一个环节没处理好，跑起来就是一串随机乱码。
我最初做这个方案的动机很简单——板子要跑一个三四十MB的AI模型，片上SRAM只有几百KB，外挂普通四线PSRAM又嫌带宽不够，SDRAM引脚又多得吓人。翻了一圈器件手册，最终锁定了Octal PSRAM + XSPI这条路。这篇文章就把整个从选型到调通再到压力测试的过程完整记录下来，给正准备做类似大内存方案的开发者做个参考。
1. 项目背景与整体设计思路：128MB内存到底用来干什么
1.1 为什么需要128MB内存
先算一笔账。假设你要在MCU上跑一个30MB的神经网络模型，光权重就是30MB，推理过程中每一层的中间激活值又要额外占几MB到十几MB不等。再加上采集到的音频缓冲、图像帧缓冲、日志环形队列，还有文件系统想要个RAM盘做临时缓存——这么一算，64MB都显得紧张，128MB才算是比较宽裕。
片上SRAM就那么大，比如ESP32-P4这类芯片片上SRAM也就几百KB，跑复杂应用连零头都不够。外扩内存就成了唯一出路。SDRAM虽然便宜容量大，但需要专门的内存控制器、大量地址线和数据线，引脚压力很大；Flash能做XIP执行代码，但随机写入寿命和速度都有限制。PSRAM（伪静态随机存储器）正好卡在中间：接口简单，像Flash一样用SPI/XSPI就能接，读写的随机访问特性又和SRAM一致，非常适合做MCU的大内存扩展。
1.2 方案选型：为什么是Octal PSRAM + 单XSPI
常见的外扩PSRAM有四线（Quad）和八线（Octal）两类。四线PSRAM一次传4bit，八线一次传8bit，配合DDR模式（时钟上升沿和下降沿都传输数据），带宽差距直接翻倍。
| 接口类型 | 数据线宽度 | 典型模式 | 理论带宽（80MHz DDR） | 引脚开销 |
|---|---|---|---|---|
| Quad PSRAM | 4bit | DDR | 80MB/s | 6~7根 |
| Octal PSRAM | 8bit | DDR | 160MB/s | 10~12根 |
| SDRAM | 16bit | SDR | 100MB/s | 25根以上 |
选择Octal PSRAM的原因很直接：带宽够高，引脚又不像SDRAM那样夸张。而选择“单XSPI双片选”而不是两条独立XSPI总线，则是从PCB布线、地址统一性和成本三个角度权衡的结果。
如果使用两条独立XSPI总线接两颗PSRAM，MCU需要两套控制器外设、两套数据线，地址空间还得分开管理；单XSPI接两颗芯片只需要多引一根片选线CS1，两颗PSRAM的数据线、时钟线全部共享，在系统层面还能通过EXTENDMEM把两个片选的地址空间拼接成一个连续的大块内存，从开发和布线角度都省事得多。
1.3 EXTENDMEM机制解决了什么问题
MCU的CPU能访问的内存范围是由地址总线决定的，通常只有几十到几百MB的编址空间，而且大部分还要留给外设寄存器和片上SRAM。128MB的PSRAM如果只靠普通的内存窗口去访问，一次只能看到一小块，其他部分得靠软件翻页切换，复杂度直接爆炸。
EXTENDMEM机制的核心作用就是解决这个地址空间不够用的问题：它把外部PSRAM的物理存储空间通过硬件映射窗口暴露给CPU，使CPU可以像访问片上SRAM那样直接对这个大块内存进行读写。配合Cache机制，连续访问的命中率很高，程序跑起来不会因为走外部总线就慢到不可接受。
这个机制带来的最大便利是“透明”。PSRAM映射完成后，你可以直接在外部内存上分配C数组、跑memcpy、放任务栈，甚至把堆空间整体划到PSRAM里，开发体验和用内部SRAM几乎没有区别。
2. 硬件设计与器件选型：Octal PSRAM、XSPI双片选的关键细节
2.1 Octal PSRAM芯片怎么选
市面上常见的Octal PSRAM主要来自AP Memory、ISSI等厂商。以AP Memory的APS512系列为例，单颗容量就是512Mbit（64MB），接口支持Octal DTR（Double Transfer Rate）模式，正好符合这个方案的需求。
选型时我关注的几个参数按优先级排列如下：
- 容量与封装：确认选的是512Mbit（64MB）而不是256Mbit（32MB），封装尽量选有大焊盘、手工好焊接的型号。
- 工作电压：1.8V和3.3V两个版本都有，需要和MCU的IO电平匹配。如果MCU的XSPI接口电平是1.8V，那PSRAM也选1.8V版本，省去电平转换。
- 工作频率：看芯片支持的最高XSPI时钟频率，稳定方案一般选133MHz甚至更高规格的，留出软件降频的余量。
- DQS信号：部分Octal PSRAM型号带DQS（数据 strobe）引脚，用于更高频率下的信号采样对齐。有DQS的型号高频稳定性更好，走线也要求更严格。
- 低功耗模式：确认芯片支持Deep Power Down模式，方便在系统休眠时把PSRAM电流压下来。
2.2 单XSPI双片选硬件的正确接法
两颗Octal PSRAM接同一个XSPI口，接线逻辑不复杂，但细节决定成败。以常见的2x64MB为例，MCU和两颗PSRAM之间的连接关系如下：
- DQ0-DQ7：8根双向数据线，两颗芯片直接并联接到MCU的XSPI数据引脚。
- CLK：时钟线并联，同一个时钟源同时驱动两颗芯片。
- CS0、CS1：两颗PSRAM的片选分别接到MCU的两个XSPI片选引脚，这是“双片选”方案的关键。
- RESET#：每颗芯片的复位脚，可以统一接到MCU一个GPIO，也可以直接通过电阻拉高，由硬件上电自动复位。
- VCC/GND：电源引脚尽量分别走线，避免共享过长的电源路径。
这里有个容易忽略的点：数据线的上拉/下拉。Octal PSRAM的数据引脚在未选中时是高阻态，但如果电路板走线比较长，高阻态引脚容易耦合噪声，导致下一次片选时读到脏数据。建议在DQ0-DQ7上各加10kΩ左右的上拉电阻（具体根据芯片手册推荐值调整），CS#、RESET#这些控制引脚也加上默认电平保证，避免上电瞬间误触发。
2.3 走线与供电的实测教训
Octal PSRAM在DDR模式下时钟频率跑到100MHz以上，这时PCB走线就不能随便乱拉了。8根数据线尽量做到等长，彼此之间的长度差控制在几十mil以内，时钟线尽量短，所有信号线避免出现长stub分支。
我最早用飞线板验证方案时，40MHz都能跑出随机位错误，两根数据线之间长度差了几厘米，信号歪歪扭扭。后来重新画了规整的PCB，把等长控制好，133MHz DDR模式才稳定下来。如果你只是想在开发板上飞线验证，建议先保守地降低时钟频率，把功能跑通再说。
供电也不能忽视。两颗PSRAM同时工作时的瞬态电流不小，尤其是刷新周期重叠时电流峰值会叠加。每个芯片的VCC和VDDQ旁边都放一组0.1uF+1uF的去耦电容，电源网络的主干尽量走宽线或铺铜，实测下来电压纹波对稳定性影响很大。
3. EXTENDMEM机制解析：软件配置与内存映射方法
3.1 EXTENDMEM到底是什么
EXTENDMEM本质上是一种硬件内存映射机制，它把外部存储器的物理空间重映射到CPU能直接寻址的地址范围内。和“软件读写外部设备”不同，EXTENDMEM映射后的内存区域具备完整的系统级地位——CPU的普通load/store指令可以直接访问，DMA可以读写，Cache也能参与缓存。
类比一下：没有EXTENDMEM时，你访问大块PSRAM就像是通过一个只能看到一部分内容的小窗口往里看，想看到窗口外的内容必须请人帮忙移动窗户；有了EXTENDMEM，相当于把这间大房子所有的门全部打开了，你可以在房间里自由走动。
在ESP-IDF这类SDK里，EXTENDMEM的使能配置通常在menuconfig中完成，系统启动阶段会自动完成XSPI控制器初始化、PSRAM时序配置、地址映射建立等步骤。SDK还负责把映射好的PSRAM注册到堆分配器，使得普通的malloc或者heap_caps_malloc可以直接从PSRAM上分配内存。
3.2 ESP-IDF中的配置步骤
在ESP-IDF环境中，这个方案对应的大致配置流程如下（不同版本菜单路径略有出入，思路一致）：
第一步：打开外部内存支持。进入menuconfig的Chip- or board-specific配置项，找到EXTENDMEM / PSRAM相关选项，使能外部PSRAM，并把模式设置为“External RAM only”或“Mirror external memory into SRAM address space”等可用模式。
第二步：设置容量与片选。如果有“PSRAM数量/容量”相关选项，选择两片64MB、总容量128MB的模式。这个设置会告诉系统两个CS都要初始化。
第三步：配置XSPI时钟和DDR模式。先选一个保守的时钟（比如80MHz DDR）确保能点亮，稳定之后再逐步提高。
第四步：检查启动日志。初始化完成后的启动日志里一般会打印PSRAM总容量和映射地址信息，确认显示的是128MB而不是64MB。
#include "esp_psram.h" #include "esp_heap_caps.h" void app_main(void) { // 显式调用PSRAM初始化（一般系统启动时已自动完成，这里是示例） esp_err_t ret = esp_psram_init(); if (ret != ESP_OK) { printf("PSRAM init failed: %s\n", esp_err_to_name(ret)); return; } // 获取PSRAM总容量 size_t psram_size = esp_psram_get_size(); printf("PSRAM total size: %zu MB\n", psram_size / (1024 * 1024)); // 获取堆分配器中PSRAM区域的总量 size_t spiram_heap = heap_caps_get_total_size(MALLOC_CAP_SPIRAM); printf("SPIRAM heap available: %zu MB\n", spiram_heap / (1024 * 1024)); // 在PSRAM上分配一块32MB缓冲区 uint8_t *big_buf = heap_caps_malloc(32 * 1024 * 1024, MALLOC_CAP_SPIRAM); if (big_buf != NULL) { memset(big_buf, 0xA5, 32 * 1024 * 1024); printf("32MB block allocated and written on PSRAM.\n"); } }3.3 两个CS的地址映射关系
EXTENDMEM在逻辑上会把CS0和CS1的PSRAM分别映射到不同的地址窗口。虽然两个窗口在实际布局中有各自的基址，但经过SDK的封装和堆分配器的统一管理，上层代码看到的是一块完整的、连续的大内存区域。
CS0和CS1的边界处往往最容易出问题。如果只把CS0初始化好了、CS1没初始化，实际可用的就只有64MB，而且系统可能不会主动报错。我在调试时就遇到过只挂了一颗芯片也显示“一切正常”的情况，所以务必检查启动日志中打印的容量是否为128MB，或者直接做一次跨全地址范围的写读测试验证。
判断映射是否正确还有一个技巧：从编译生成的map文件里查看外部内存段的基址和大小，或者写一小段代码读CS0末地址和CS1首地址的物理相邻性，确认边界是连续的。
4. 实操过程与性能验证：读写测试、带宽测试全流程
4.1 搭一个最小的验证工程
先不急着把模型搬上来，做验证工程要坚持“最小可运行”原则。我的步骤是：
- 准备好MCU核心板和焊接了两颗Octal PSRAM的测试板。
- 建一个新工程，先把串口日志跑通。
- 在menuconfig中完成EXTENDMEM配置，上电看启动日志是否准确显示128MB。
- 日志确认没有问题后，写一个简单的分配+读写测试，跑通基础功能。
- 最后再上完整的压力测试和性能测试。
一步一验证的好处是，一旦出问题能快速定位到具体环节，不会多个变量混在一起无从下手。
4.2 全地址写读压力测试怎么做
这里分享一个实用的压力测试代码：对128MB空间逐字节写一个由地址映射生成的pattern，再读回比对。用地址相关pattern比全写0x55、0xAA更能暴露地址线、片选切换和数据线上的问题。
#include <stdio.h> #include <string.h> #include "esp_heap_caps.h" static void psram_full_stress_test(void) { // 分配完整128MB空间 uint8_t *base = heap_caps_malloc(128 * 1024 * 1024, MALLOC_CAP_SPIRAM); if (base == NULL) { printf("Failed to allocate 128MB on PSRAM\n"); return; } size_t total = 128 * 1024 * 1024; printf("Writing pattern to %zu bytes...\n", total); // 逐字节写入地址相关pattern for (size_t i = 0; i < total; i++) { base[i] = (uint8_t)(i * 31 + 7); } printf("Verifying pattern...\n"); size_t errors = 0; for (size_t i = 0; i < total; i++) { uint8_t expect = (uint8_t)(i * 31 + 7); if (base[i] != expect) { if (errors < 16) { printf("Mismatch at 0x%08zx: expect 0x%02x, got 0x%02x\n", i, expect, base[i]); } errors++; } } printf("Stress test finished, total errors: %zu\n", errors); free(base); }第一次跑128MB逐字节写读会有点慢，这是正常的。先跑通这个测试，确认两颗芯片都在正常工作，再做高性能测试。
4.3 带宽测试与理论值对比
带宽测试用大块memcpy最直观：分配两个8MB或32MB的PSRAM缓冲区，拷贝后用定时器计算耗时。
#include "esp_timer.h" #include "esp_heap_caps.h" static void psram_bandwidth_test(void) { size_t block = 32 * 1024 * 1024; // 32MB uint8_t *src = heap_caps_malloc(block, MALLOC_CAP_SPIRAM); uint8_t *dst = heap_caps_malloc(block, MALLOC_CAP_SPIRAM); if (src == NULL || dst == NULL) { printf("Bandwidth test allocation failed\n"); return; } memset(src, 0x5A, block); int64_t t0 = esp_timer_get_time(); memcpy(dst, src, block); int64_t t1 = esp_timer_get_time(); double elapsed_us = (double)(t1 - t0); double bw_mb_s = (double)block / elapsed_us; // bytes/us -> MB/s printf("memcpy 32MB, elapsed %.2f ms, bandwidth %.1f MB/s\n", elapsed_us / 1000.0, bw_mb_s); free(src); free(dst); }理论上，XSPI在133MHz DDR模式下，8条数据线每个时钟周期传输16bit（上下沿各8bit），理论峰值带宽是：
133MHz × 16bit ÷ 8 = 266MB/s
实测值通常在200MB/s上下，和理论值有差距是正常的，原因包括：XSPI控制器自身的命令/地址阶段开销、PSRAM内部刷新周期抢占总线、Cache策略影响、memcpy的函数实现不是纯DMA等。
4.4 实测数据参考
| 测试项 | Quad PSRAM（80MHz DDR） | Octal PSRAM（133MHz DDR） |
|---|---|---|
| 理论带宽 | 80MB/s | 266MB/s |
| 实测memcpy带宽 | 50~60MB/s | 180~210MB/s |
| 128MB逐字节写读时间 | 约5~8秒 | 约2~3秒 |
| 随机地址读写（4字节粒度） | 受总线延迟影响明显 | 受总线延迟影响明显 |
实测下来，Octal PSRAM相对Quad的提升是实打实的，尤其是大块拷贝场景。但要注意，两颗PSRAM共享同一条XSPI总线，总带宽是共享的——不管挂一颗还是两颗，整条总线的吞吐上限不变，增加第二颗PSRAM带来的是容量翻倍，而不是带宽翻倍。
5. 常见问题与排查经验：初始化失败、数据错乱、Cache一致性
5.1 启动初始化失败或只识别到64MB
这个是最常见的坑。现象是启动日志里PSRAM容量显示64MB而不是128MB，或者直接初始化失败。
排查顺序如下：
- 确认两个CS引脚都正确连接且没有虚焊。用万用表量CS0、CS1到MCU引脚的通断。
- 确认SDK配置里选择了双片选/128MB模式。有些SDK默认只初始化第一个CS，需要显式开启第二个。
- 确认芯片的RESET#引脚电平正确。RESET#如果悬空，芯片可能处于异常状态。
- 把XSPI时钟降到最低测试。初始化失败大概率是时钟太高导致时序不满足，降低时钟能先排除这个问题。
5.2 压力测试出现随机错位
跑一会儿出现零星错误，是常见的第二类问题。这类问题最折磨人，因为它不稳定、不好复现。
我踩过的坑主要有三类：
信号完整性问题。数据线、时钟线走线不等长，或者走线过长导致信号边沿劣化。解决办法是降低时钟频率测试，如果降频后错误消失，基本可以断定是信号完整性问题，需要从PCB走线上解决。
PSRAM时序配置问题。XSPI控制器的读写时序参数（例如tCL、tCD、tCSS）和PSRAM芯片数据手册要求不匹配。可以尝试在SDK中调整XSPI时序参数，或者换用芯片厂商推荐的初始化序列。
电源纹波问题。高温或大电流场景下电压跌落导致数据出错。可以在PSRAM电源输入端加示波器观察波形，看看是否有明显的周期性跌落。如果看到，就需要加强电源去耦。
5.3 Cache一致性：DMA和CPU互相看不到数据
EXTENDMEM映射的PSRAM区域默认可能带Cache，CPU读数据时会走Cache，DMA写PSRAM则直接访问物理存储。于是会出现“DMA明明写进去了，CPU一读却是旧数据”的情况，反过来也一样。
解决办法是在DMA操作前后主动做Cache同步。以ESP-IDF的esp_cache_msync为例：
#include "esp_cache.h" void dma_write_psram(uint8_t *dma_buf, size_t size) { // DMA写之前，把CPU侧Cache中脏数据写回PSRAM esp_cache_msync(dma_buf, size, ESP_CACHE_MSYNC_FLAG_DIR_C2M); // 启动DMA写操作 // ... // DMA写完成后，让CPU侧Cache失效，强制重新从PSRAM读取 esp_cache_msync(dma_buf, size, ESP_CACHE_MSYNC_FLAG_DIR_M2C); }这条经验很重要：千万不要为了省那几次msync调用而忽略Cache同步，偶发的错误数据排查起来远比多调几次API更耗时间。
5.4 高温环境下频繁出错
大容量PSRAM工作一段时间后发热明显，尤其两颗同时跑满负载时，温度上升可能导致时序裕量不足，出现高频偶发错误。对策有几个：降低XSPI时钟频率留出裕量、改善PCB散热（铺铜、散热孔）、软件层加温度监测，温度过高时主动降频。
如果项目要求宽温环境，选型时就要注意芯片的温度等级，工业级型号通常-40℃到85℃，和消费级相比价格高但可靠性完全不同。
| 问题现象 | 可能原因 | 排查/解决方案 |
|---|---|---|
| 启动识别到64MB | 第二CS未启用/CS1引脚未接好 | 检查配置、检查焊接 |
| 初始化直接失败 | 时钟过快、供电异常 | 降频、检查电源纹波 |
| 压力测试偶发错位 | 信号完整性/时序参数 | 降频确认、调整时序、优化走线 |
| DMA写后CPU读旧数据 | Cache一致性 | 使用msync做Cache同步 |
| 高温后错误增多 | 时序裕量不足 | 降频、改善散热、加温控 |
最后再说说这次项目下来我个人的体会。128MB内存带给开发者的想象空间确实很大，以前不敢想的事（比如在MCU上放几十MB的模型和数据集）现在有了落地的可能。但大内存不是靠堆硬件就完事的，EXTENDMEM映射是否完整、Cache同步是否到位、PCB走线是否够规整，每一层都可能成为瓶颈。如果下次再做类似方案，我会在原理图阶段就把走线等长、电源去耦、测试点这些细节都规划好，而不是等软件调不通了再回头查硬件。另外一个小建议：方案定型前，一定要跑一轮8小时以上的高温压力测试，用极端pattern和全地址遍历去验证稳定性，这个步骤能帮你省去后面整条产品线的大麻烦。
