工业控制器里最容易被忽略、但一旦出事就是大事的往往是数据存储。程序写好了、逻辑调通了、通信跑顺了最后却发现设备掉电一次参数归零或者日志丢了现场死活查不出故障原因。我做工业控制器这块有年头了对这种数据去哪儿了的痛感特别深。这一篇是硬件系列的第十二篇就把 STM32FPGA 架构下分级存储的方案完整拆开讲为什么把 EEPROM、NOR Flash、SD 卡同时塞进一块板子三者各自该干什么、不该干什么硬件上怎么接、驱动上怎么写、掉电怎么扛。内容偏硬件和底层驱动适合正在做运动控制、仪器仪表、边缘网关这类设备的工程师参考。1. 为什么一个控制器里要塞三种存储颗粒先想清楚数据的分级逻辑很多人做存储选型是一拍脑袋的容量不够就加一片 Flash跑个文件系统就上 SD 卡参数需要掉电保存就随便找个 EEPROM。结果往往是启动慢、寿命短、掉电丢数据出了问题都不知道该怪谁。我自己的经验是设计存储架构之前先把手里的数据按照生命周期分个类方案自然就清晰了。1.1 工业控制器里到底有哪几类数据拿一个典型的运动控制或过程控制设备举例数据大致能分成三类。第一类是运行参数比如 PID 系数、脉冲当量、通信地址、校准零点、报警阈值。这类数据的体量很小从几十字节到几 KB 顶天了但是改动频繁——调试的时候一天改几十次很正常而且每一项都直接关系到设备能不能干活。这类数据的核心诉求是掉电立刻保住、单字节原子写入、足够长的擦写寿命。第二类是固件和系统关键信息包括 Bootloader 备份、应用程序镜像、FPGA 配置文件、出厂校准表。这类数据往往是几千 KB 到几 MB 级别改动的频率极低可能几个月才升级一次但绝不能丢一旦写坏设备就变砖了。它们对存储介质的要求是按扇区快速擦写、数据完整性校验、支持安全升级的备份切换机制。第三类是运行日志和采集记录比如温度曲线、故障记录、通信报文、计件数量。这类数据在掉电前需要尽可能多地保留体量是持续增长的一天几百 KB 到几十 MB 都很正常。日志丢了不致命但客户要追溯故障原因的时候拿不出来就非常被动。这三类数据放到同一种介质里彼此拖后腿。全塞 EEPROM容量不够、日志根本写不下全塞 SD 卡每次上电都要挂载、人力物力都耗不起而且参数写入一个小扇区也要承受文件系统的写放大和磨损全塞 NOR Flash成本高、频繁参数更新会消耗擦除寿命日志量一大也不划算。1.2 分级存储的核心理念让每颗芯片只干它最擅长的事所以我的习惯是把存储硬件拆成三级每级对应上面一类数据层级介质容量典型值适合的数据核心优势主要代价L0EEPROM (I2C)2KB~512KB运行参数、标定值按字节原子写、寿命高达百万次、掉电不丢容量小、总线速率低L1NOR Flash (SPI)8MB~64MB固件镜像、FPGA配置、关键日志归档随机读快、扇区擦写好控制、支持 XIP擦写寿命约10万次、扇区擦除较慢L2SD 卡 (SDIO/SPI)512MB~32GB批量运行日志、历史曲线容量大、即插即用、可离线分析文件系统复杂、掉电与热插拔风险顺着这张表你就能理解标题里STM32FPGA 分级存储的布局意图了STM32 负责业务逻辑和参数管理FPGA 去兜底那些对时序要求高的存储操作比如 NOR Flash 的高速连续写、SD 卡的数据流缓冲。两者各管一道才不会出现MCU 忙于写日志、导致实时控制周期被 stretch这种事情。1.3 在这个方案里 STM32 和 FPGA 各自的分工具体到我的项目里分工是这样的。STM32 独占 EEPROM。参数读写本身是低频操作I2C 总线在 STM32 上处理完全够用没必要让 FPGA 插一脚。MCU 挂了也不至于连参数都读不了。NOR Flash 挂在 FPGA 侧。为什么因为工业控制器有时候需要在控制周期内连续记录高速采集的数据比如振动波形、电流瞬态这类数据吞吐大、实时性强STM32 的 SPI 外设扛不住那么高频的中断写入如果让 MCU 用轮询方式写其他任务就全卡住了。让 FPGA 直接把数据流从 FIFO 灌进 Flash效率和确定性都更高。SD 卡也挂在 FPGA 侧专门用来承接固化后的日志文件流。MCU 只需要通过 FPGA 的转发接口按块提交日志数据文件系统甚至可以在 MCU 侧跑也可以只做裸分区管理。这样 SD 卡读写的大量底层时序、CRC 校验都由 FPGA 逻辑保证不占用 MCU 的 CPU 时间。一句话总结我的设计原则按照谁对实时性要求最高、谁就离 FPGA 最近来分配总线和存储外设。STM32 管好策略FPGA 管好时序存储系统才真正称得上分级。2. EEPROM 这一级参数改错了要能反悔掉电了要能保住先聊 L0 这一级。EEPROM 在工业产品里是参数安全的最后一道底裤。方案里选的是 I2C 接口的 24C 系列比如 AT24C256 或者 Microchip 的 24AA512具体容量视参数表的长度而定。绝大多数控制器几十个参数就够256Kbit 的芯片能写几千字节配置余量充足。2.1 为什么不让 STM32 用内部 Flash 模拟 EEPROM很多项目为了省一颗料直接用 STM32 内部 Flash 模拟 EEPROM。我试过小批量、实验室环境确实能跑但在工业现场我强烈不建议。原因有三条。第一内部 Flash 需要整页擦除再写入不是字节级原子操作如果掉电时机恰好落在擦了一半的时刻整个参数页就全废了。第二写入前要关全局中断写操作期间系统实时性受影响你在中断里改一个参数可能正好把伺服使能的沿给卡掉了。第三Flash 擦写寿命通常只有一万到十万次而参数更新频繁的产品用一两年就可能达到上限一旦超限整颗 MCU 的程序区都跟着遭殃得不偿失。外挂一颗 EEPROM 的成本就几毛钱换来的是字节级原子写、百万次寿命、独立于程序存储的安全性这笔账怎么算都划算。2.2 硬件连接里那几个容易翻车的地方先看管脚连接。24C 系列的 SCL/SDA 分别接 STM32 的 I2C1 对应引脚A0/A1/A2 三个地址脚在单颗使用的时候全部接地地址就是 0xA0。WP 写保护脚是重点很多工程师直接接地等于永远可写我习惯用一个 GPIO 来控制它平时拉高写保护仅在写入参数的前几十毫秒拉低。这样即使软件跑飞也不至于把 EEPROM 内容刷掉。上拉电阻这个细节我要单独拎出来说。I2C 是开漏总线SCL/SDA 必须接上拉。很多人随便选了个 4.7kΩ 就完事但要注意总线速率和总线电容。400kHz 快模式加上几条长走线4.7kΩ 往往拉不起来波形变圆导致通信错误。我一般控制在 1kΩ~2.2kΩ 之间如果 EEPROM 和 MCU 在板内很近、线短2.2kΩ 实测最稳。另外强烈建议在 SCL/SDA 上各串联一个 22Ω 的小电阻放在靠近 MCU 引脚那一端对抑制高速边沿的振铃有奇效。电源去耦也别省EEPROM 是纯数字芯片虽然不至于像模拟器件那样敏感但我见过因为 VCC 纹波太大导致 I2C 写操作偶发失败的案例。芯片旁边的 100nF 电容别省而且电源要先经过磁珠或 RC 滤波再进芯片。2.3 驱动要处理好三个看不见的坑写周期、页边界、应答第一坑24C 系列每次字节写或页写之后内部需要 3~5ms 的写周期 tWR在 tWR 期间芯片不响应任何命令也不产生 ACK。很多人写驱动时发完数据就不管了下一条写指令直接失败。正确的做法是写完一字节或一页后轮询设备地址直到收到 ACK 为止这样既等待了内部写完成也确认了器件活着。第二坑页写跨页边界会自动回卷。24C256 的页大小是 64 字节如果你从地址 0x3F 开始连续写 10 个字节那么地址 0x3F 之后的地址会回卷到 0x00后面的数据全写到页头去了。驱动里必须做跨页拆分我通常写一个按目标页分片写入的函数保证每次调用写入的字节数不超过当前页剩余空间。第三坑硬件 I2C 外设有时会因总线错误进入 BUSY 状态常见的是上电时 SDA 被外部拉低或者通信过程中被干扰。我现在的驱动里每次写操作前先检查 I2C 总线的 BUSY 标志如果异常就复位 I2C 外设和 GPIO避免驱动卡死在等待事件上同时在存储数据里附加 CRC 校验和双份镜像写入时先写备份区、再写主区读取时校验失败自动切换备份区相当于参数区的 RAID 1。2.4 掉电保护策略掉电监测要快、要早、要给 EEPROM 留出时间工业控制器的掉电场景跟开发板不一样不是拔插 USB 这么温和。现场是三相电闸一拉控制电源由输入端的大电容维持几十毫秒然后断崖式下跌。EEPROM 写一个字节需要大约 5ms 的供电保证所以掉电检测必须在电压还没跌到 MCU 最低工作电压之前就触发中断。我的典型做法电源入口处放置一个电阻分压网络检测 24V 直流母线电压当它降到 20V 左右时比较器翻转触发 STM32 的一个外部中断。这个中断的优先级设到最高中断里只做一件事把当前需要保存的参数立刻写入 EEPROM然后置标志让主循环停止业务。同时在 STM32 的 VDD 引脚附近加大容量的储能电容保证从检测到掉电到EEPROM 写完期间电源不掉链子。实测 1000μF 的储能电容可以给系统多扛 50ms 以上足够写完一整页参数。这里有个不少人忽略的点FPGA 的配置 RAM 在掉电后内容即失如果你的参数里有涉及 FPGA 的配置项比如编码器方向取反、滤波系数必须记住在掉电保存时把当前生效值和下次上电加载值分开设计。我在参数表里直接规划了生效模式字段有些参数是立即生效加掉电保存有些是仅本次运行生效重启恢复默认。这样既灵活又不会出现灾难性的误写。3. NOR Flash 这一级固件要能升级、配置要安全还要扛住高速采样写入L1 级我选 SPI NOR Flash型号上用 W25Q64 或者国产兼容料居多。容量根据要存的东西定一份 STM32 固件约 1.5MB一份 FPGA bit 文件约 800KB再加一个出厂校准表区域64Mbit8MB的 NOR Flash 非常宽裕。若需要存高速波形数据建议上 128Mbit 甚至更大成本和封装差别都不大。3.1 为什么高速采集数据的落盘放在 FPGA 而不是 MCU这是个架构问题。高速 ADC 采样数据如果走 STM32 的 SPI一次 DMA 搬运都要占用总线采集 1MSPS × 2 字节 × 多通道吞吐量轻松到几十 MbpsMCU 的 CPU 忙不过来还可能影响伺服控制环的实时响应。FPGA 做这事有天然优势内部可以做深度 FIFO接收 ADC 数据流后按扇区缓冲拼装然后以 SPI Master 方式连续写入 NOR Flash。整个写 Flash 的时序由 FPGA 状态机精确控制MCU 完全不需要参与。要读取数据时MCU 给 FPGA 发一个读地址读长度命令FPGA 再按地址把数据吐回来。这样 Flash 读写的带宽压力被 FPGA 隔离掉了CPU 只处理解析后的有效信息。3.2 FPGA 控制 SPI NOR Flash 的时序要点命令序列、状态轮询、页编程NOR Flash 的写入流程是固定的写使能0x06→ 页编程命令0x02→ 地址 → 数据 → 等待 WIP 位清零。在 FPGA 里实现这些命令不难但有几个细节直接影响可靠性。第一个细节是写使能的时序。每次页编程、扇区擦除操作执行之前必须先发写使能命令否则 Flash 会拒绝执行。如果状态机在异常情况下跳转错了状态少发了 0x06后面的操作会静默失败连错误提示都没有。我调试时吃过这个亏后来在状态机里加了检查操作是否真的执行成功的环节。第二个细节是等待操作完成的方式。有很多人习惯固定延时比如擦除一个扇区就 sleep 50ms。但不同品牌、不同批次的 NOR Flash 擦除时间差异很大典型值 50ms最大值可能到 400ms。固定延时要么太保守浪费时间要么太冒进导致操作中途被下一个命令打断。正确做法是轮询读状态寄存器0x05看 WIP 位bit0直到它为 0。这个轮询在 FPGA 里就是一小段循环状态不占 CPU也不用猜时间。第三个细节是页编程的边界。SPI NOR Flash 页大小通常是 256 字节连续写入超过页边界会回卷和 EEPROM 的页回卷机制类似。FPGA 里做写入逻辑时务必将要写的数据按源地址和目的地址双重对齐拆分每次页编程不超过 256 字节并处理好两个页之间跨页封装的地址计算。下面给一个简洁的 Verilog 状态机骨架展示页编程命令的发送流程供参考localparam IDLE 3d0, WE 3d1, PGM_CMD 3d2, PGM_ADDR 3d3, PGM_DATA 3d4, WAIT_WIP 3d5; always (posedge clk) begin case (state) IDLE: if (start_pgm) state WE; WE: state PGM_CMD; // 已拉低CS发送0x06 PGM_CMD: state PGM_ADDR; // 发送0x02并开始送3字节地址 PGM_ADDR: if (addr_done) state PGM_DATA; PGM_DATA: if (byte_sent pgm_len) state WAIT_WIP; WAIT_WIP: if (wip_clear) begin state IDLE; pgm_done 1b1; // 拉高CS完成一次页编程 end endcase end这个状态机里最值得注意的就是 WAIT_WIP拉高 CS、发读状态寄存器命令、读取一个字节、检查 bit0、重复直到清零。忘了这一步你的 Flash 控制器就像个没有刹车系统的车跑得越快死得越快。3.3 固件双备份与掉电变砖的最后一公里防线NOR Flash 不能只规划一个应用区位。工业现场固件升级过程中突然断电是最常见的变砖场景。所以我规划 Flash 分区时永远用一个 Boot 区 两个 App 槽位的方式当前运行的固件在一个槽位升级包写入另一个槽位全部校验成功后再切启动标志。这样即使升级过程中掉电下次上电还是能回退到旧固件设备不至于变成砖。FPGA 的配置也有类似考虑bit 文件存储在 NOR Flash 里FPGA 上电时通过 SPI Slave 或 SelectMAP 方式加载。如果 bit 文件写到一半就断电下次上电 FPGA 加载的就是半个文件轻则管脚毛刺乱飞重则配置失败。所以我在 FPGA 配置文件之前加了个 32 位 CRC 字段FPGA 加载完成后回读校验失败则向 MCU 报告MCU 再从备份槽位重新下发配置。3.4 掉电时 NOR Flash 的写入保护策略NOR Flash 本身有 WP# 引脚和状态寄存器的 BP 位。对于存放 Bootloader 和出厂校准数据的区域我会把状态寄存器的 BP0~BP3 设为写保护防止异常程序把这些区域擦掉。平时正常运行时MCU 不需要往这些区域写数据所以保持写保护状态完全没影响只有进入固件升级模式才临时解锁。掉电检测方面NOR Flash 的高速写流程不像 EEPROM 那么好打断。一个 4KB 扇区擦除正在进行时突然掉电Flash 内部状态机可能停留在中间状态。所以 NOR Flash 区域要有操作日志机制每次写操作开始前先在一个固定的小扇区里记录正在写哪一块、数据 CRC 是多少写完后再标记完成。上电时扫描这个日志如果发现上次操作未完成就回滚或重写保证数据一致性。4. SD 卡这一级日志文件系统与数据流的缓冲与封口L2 级的 SD 卡承担的是大而杂的日志。我见过很多工程师在这一级栽跟头FATFS 挂不上、文件写一半断电、文件系统损坏读不出来。其实 SD 卡在工业环境下的坑一大半来自文件系统协议栈和掉电时序的匹配问题。4.1 挂在 MCU 还是 FPGA 侧我给出的总线分配方案标题里说的是 STM32FPGA 架构所以 SD 卡在逻辑上可以由任何一侧控制。最稳妥也最常见的方案是 SDIO 接口由 STM32 直接驱动因为 STM32 的 SDIO 外设配合 DMA吞吐量足够跑日志。但这样做的代价是 MCU 要承受文件系统的 CPU 开销和中断负担。如果是高通量、高实时性需求比如连续采集电机电流波形并保存到 SD 卡MCU 侧做会很容易挤占控制回路的时间片。所以我的做法是SD 卡物理层仍接 STM32 的 SDIO但数据路径经过 FPGA 的 FIFO 缓冲MCU 只负责按块提交数据和维护 FAT 表。FPGA 在这里起蓄水池的作用当 SD 卡写一个扇区需要几十毫秒时MCU 不会因为这几十毫秒而把控制周期拉长数据先落进 FPGA 的大 FIFOSD 卡忙完再来取。简单说MCU 只关心日志块的起始扇区和长度FPGA 负责把这一块数据流按 SD 卡的时序慢慢推出去。系统看起来既是 MCU 控制 SD 卡又是 FPGA 在扛 SD 卡时序实际上是一个职责分离的协作关系。4.2 FATFS 移植时最容易被忽略的三个配置如果你用的是 FatFS 协议栈下面几个配置直接影响工业场景的可靠性。第一个是_FS_EXFAT。现在市面上很多 SD 卡出厂默认 exFAT 或大容量 FAT32如果你只开了_FS_FAT32插上一张 64GB 的卡直接挂载失败。我在项目里干脆打开 exFAT 支持同时用f_mkfs把卡格式化成 FAT32 或 exFAT避免客户随便插张卡不识别。第二个是_USE_LFN长文件名支持。工业日志文件我习惯按日期命名比如LOG20250101_1.CSV不开长文件名就截断成LOG2025~1.CSV排查问题很不直观。长文件名本身占用较多 RAM但 STM32F4/H7 的资源完全够用。第三个是扇区缓冲。FatFS 默认_MAX_SS是 512但现在很多 SD 卡用 4KB 物理扇区。如果 SD 卡报告扇区大小是 4096 而 FatFS 还用 512 读写部分卡的兼容性会出问题。保险做法是在diskio.c里对CTRL_GET_SECTOR_SIZE正确响应并让 FatFS 的缓冲区对齐到 4 字节以上。我踩过这个坑现象就是偶尔写文件死循环——排查了一下午最终发现是 DMA 缓冲地址没对齐到 4 字节边界。4.3 日志文件的封口设计掉电后不会留下一堆损坏文件最让我头疼的问题曾经是现场拉闸后再上电看 SD 卡最近的日志文件要么是 0 字节要么 FAT 表里记录的大小与实际数据完全对不上。原因是文件系统在写入数据后并没有同步更新目录项里的大小字段掉电那一刻刚好停在数据已写、目录未更新的窗口期。解决办法是主动封口。我的日志系统是这样设计的MCU 每写完一整块日志数据立即调用f_sync或f_write后立刻f_truncate再f_lseek更新文件大小保证关键扇区及时回写。这个操作频率很低不会成为性能瓶颈但能把掉电损坏的概率降到原来的十分之一以下。更进一步我维护一个当前日志状态文件里面只存三行字当前日志文件名、最新写入扇区、最近一次同步时间。每次f_sync时顺手更新这个状态文件。掉电重启后MCU 读取状态文件就能快速定位到上次写到哪个位置跳过损坏区段从断点继续。这个设计让日志在恶劣环境下的完整性得到了质的提升。4.4 应对 SD 卡的两个物理脾气热插拔与大电流跌落工业控制器里 SD 卡通常是焊死在板上的 eMMC 或贴片 TF 卡座但也有人为了扩容做成抽屉式卡座。抽屉式问题很大客户在设备运行时拔卡总线上的电流突变可能导致 SDIO 时钟线上的毛刺把主控的 SDIO 外设打死插回一张不同容量的卡文件系统缓存与新卡参数冲突直接挂不上。我的建议是能不热插拔就别热插拔卡座加上卡检测脚 CD#检测到拔卡立刻通知 MCU 弹出并禁用 SDIO 时钟插入后必须做完整的初始化流程而不是沿用缓存参数。另外在电路上每根 SDIO 数据线、时钟线、命令线都要串联 33Ω 或 47Ω 的排阻电阻要放在靠近主控端能有效抑制走线过长带来的反射。功耗也别忘了。SD 卡写入瞬间的峰值电流可以达到 100~200mA比 NOR Flash 和 EEPROM 高一个量级。如果 3.3V 电源设计余量不足写卡瞬间电压跌落会导致卡内部电压监测复位表现就是偶尔写文件失败、错误码 0x05这类诡异问题。我在这级电源上加了一个 470μF 的电解电容和几个 100nF/1μF 陶瓷电容的组合实测写卡过程电压跌落从 200mV 降到 50mV 以内问题立消。5. STM32 与 FPGA 之间的存储访问协作命令通道、仲裁与一致性分级存储方案里三颗存储芯片不是孤立的它们都通过 STM32FPGA 的协作来服务整个系统。所以这两颗芯片之间的通信架构决定了整个存储体系能不能统一指挥、协同作战。5.1 命令通道用寄存器组还是报文协议我见过不少项目让 STM32 跟 FPGA 之间用一大片并口直接连一堆 GPIO 来传数据结果调试时对着逻辑分析仪头皮发麻。自己定协议虽然灵活但开发和排错成本太高。我的建议是走寄存器访问 轻量报文的方式在 FPGA 里实现一组寄存器映射MCU 通过地址线 数据线 读写信号访问这些寄存器所有跨时钟域的操作都在 FPGA 内部完成同步处理。这个方案的道理和裸机访问外设寄存器一样简单MCU 对存储设备的读写命令实际上是往几个特定寄存器里填内容然后置 start 位FPGA 检测到 start 后自动执行后续操作完成后置 done 位并更新状态寄存器。MCU 只需要轮询状态不需要关心底层的 SPI/SDIO 时序细节。5.2 存储访问的仲裁不能同时让两个总线大师去抢一颗芯片FPGA 里同时存在多个存储访问源ADC 采样的高速写、MCU 的参数读、固件升级通道的写、SD 卡日志的流式转发。如果这些访问不加节制地同时发起SPI 总线和 SDIO 总线会打起来。所以我在 FPGA 内部做了一个小仲裁器类似片上总线。所有存储访问请求都带着优先级标签比如固件备份写 掉电参数保存 参数读 采样日志写 普通日志写。同一时刻只能有一个请求占用对应存储介质的总线其他请求在 FIFO 里排队。这样既保证了掉电时关键操作的及时性又避免了多条总线上的信号竞争。这个仲裁逻辑只有几百行 Verilog但带来的工程意义重大存储访问的确定性得到保证不会因为一次优先级翻转导致采样数据被覆盖。调试时也只需要看一个仲裁状态寄存器就知道当前谁在用 Flash、谁在等 SD 卡。5.3 一致性视角FPGA 写数据MCU 怎么知道自己读到的不是半截MCU 读 FPGA 里缓存的采样数据时如果 FPGA 正在写同一个缓冲区MCU 可能读到半新半旧的数据。这个问题在纯软件层面解决不了必须在硬件层面加同步设计。我习惯用双缓冲乒乓切换FPGA 依次往两个缓冲区写写完一块就切换标志并产生一个中断给 MCUMCU 只读当前非活跃的缓冲区。这样 MCU 永远读不到正在被写入的数据数据完整性天然保证。要做 CRC 校验也可以在每块数据的末尾由 FPGA 追加 32 位校验值MCU 读取后立即验证。这个方案虽然费一点 BRAM 资源也就是几 KB 级别但大大减少了 MCU 与 FPGA 之间的一致性 bug。否则你会在偶尔多读两个字节偶尔读到旧数据这类魔幻问题上耗掉好几个晚上。5.4 掉电瞬间的协作状态机MCU 和 FPGA 要按剧本走处理掉电时MCU 和 FPGA 必须有一个明确的配合时序否则两边同时操作存储介质会产生致命冲突。我的设计是这样掉电检测触发 STM32 外部中断MCU 立刻向 FPGA 发一个紧急冻结请求通过一个专用 GPIO 管脚拉高来传递FPGA 收到冻结请求后停止所有非关键写入操作将当前 FIFO 里剩余的数据尽力写入 NOR Flash完成一个内部优雅停止状态MCU 利用储能电容提供的剩余电量完成 EEPROM 参数保存FPGA 确认写完后通过握手位通知 MCU我已就绪MCU 记录掉电标志到 BKP 寄存器等待电源归零。这套流程总时长控制在 20~30ms 内配合储能电容完全可行。关键是不能让 MCU 和 FPGA 同时写同一片 NOR Flash所以冻结请求的优先级要高于一切存储操作。6. 验证方法与踩坑清单存储系统怎么测才能放心交付代码写完了、板子能跑了不等于存储方案可以交付。我在实际项目中总结了一套验证矩阵专门用来压测存储链路发现过不少平时没事、现场必炸的隐患。6.1 长时间写读循环用高温老炼思路压测每一级存储对 EEPROM我跑的是参数区间反复写读循环全地址随机写、回读比对、掉电中断随机注入。测试程序会自动记录出错地址和出错类型连续跑 24 小时以上。对 NOR Flash重点是扇区擦除后的数据完整性检查以及扇区边界回卷的统一性验证。对 SD 卡我用一份独立的测试固件连续写满卡容量的 30%再完整回读比对中途人为断电多次统计文件损坏率和 FAT 表异常率。这些测试不是软件自测而是板级硬件测试也就是要带着电路板上的实际信号质量一起来测。尤其是 SDIO 总线只有在实际跑数据流时信号完整性问题才会显形。6.2 掉电瞬间注入比看门狗更严格的断电虐机掉电测试的标准做法是让系统正常运行并持续写入存储然后用一个可以设定角度的继电器或固态开关在市电的不同相位随机切断电源循环 2000 次以上。每次掉电后设备重新上电检查 EEPROM 参数、NOR Flash 关键区、SD 卡文件系统是否完好。我遇到过的最隐蔽问题就是在这个测试里暴露的EEPROM 的写保护脚由一个 GPIO 控制掉电瞬间该 GPIO 被释放为高阻上拉电阻没能维持足够快的上升沿导致写保护激活滞后几十微秒。虽然参数最终保住了但那次实际写入是侥幸完成的。后来我改成保护脚默认硬件上拉写入时 MCU 主动拉低从硬件层面兜底风险才彻底消除。还有一个值得注意的现象是反复掉电后NOR Flash 的某个扇区坏块率会显著上升。这不是颗粒质量差而是擦除命令掉电后留下了半擦除状态下一次上电回滚逻辑如果处理不当会把扇区的剩余数据也擦掉。解决方法是优化上电扫描逻辑发现上次操作标记为未完成时先做整扇区重写而不是简单擦除。6.3 现场易发问题的排查清单现象可能原因处理建议I2C 写 EEPROM 偶发无 ACK上拉电阻过大、信号沿过缓减小上拉电阻、加串阻、加大储能电容NOR Flash 写入后回读错误页写跨边界回卷、未轮询 WIP驱动层严格按页拆分写完轮询的代码别优化掉擦除扇区命令总超时擦除期间被更高优先级打断检查 SPI 总线是否被模块间复用必要时加互斥信号量固件升级掉电后无法启动没有双槽位备份机制改成 Boot双 App 槽位升级完成后再切启动标志SD 卡偶尔写文件失败电源跌落、DMA 缓冲未对齐加储能电容、检查 DMA 源地址 4 字节对齐SD 卡日志文件大小为 0掉电时目录项未更新用 f_sync 及时同步维护状态文件做断点续写上电读取参数区数据校验失败双区镜像逻辑未生效确认读校验失败后自动回切备份区并记录错误标志这张表里的每一条都是我交过学费的直接拿去用就行。6.4 写在最后的一点项目心得分级存储做完整个系统的数据安全等级上了一个台阶。但我想强调存储架构从来不是选几颗料、接几根线那么简单它本质上是对设备数据的全生命周期管理把实时性要求、寿命要求、容量要求和可靠性要求拆解到合适的介质上再靠 MCU 和 FPGA 的协作把每一条数据流管理到位。如果你正在做类似的项目我的建议是先花一周时间仔细列出设备产生的所有数据类型给每个类型打上寿命预期、容量预期、实时性预期三个标签再回来对照这篇的架构思路你会发现自己也能设计出一套合理的分级存储方案。具体的电路和代码不是死的思路才是。
STM32+FPGA工业控制器分级存储架构：EEPROM、NOR Flash、SD卡协同设计
工业控制器里最容易被忽略、但一旦出事就是大事的往往是数据存储。程序写好了、逻辑调通了、通信跑顺了最后却发现设备掉电一次参数归零或者日志丢了现场死活查不出故障原因。我做工业控制器这块有年头了对这种数据去哪儿了的痛感特别深。这一篇是硬件系列的第十二篇就把 STM32FPGA 架构下分级存储的方案完整拆开讲为什么把 EEPROM、NOR Flash、SD 卡同时塞进一块板子三者各自该干什么、不该干什么硬件上怎么接、驱动上怎么写、掉电怎么扛。内容偏硬件和底层驱动适合正在做运动控制、仪器仪表、边缘网关这类设备的工程师参考。1. 为什么一个控制器里要塞三种存储颗粒先想清楚数据的分级逻辑很多人做存储选型是一拍脑袋的容量不够就加一片 Flash跑个文件系统就上 SD 卡参数需要掉电保存就随便找个 EEPROM。结果往往是启动慢、寿命短、掉电丢数据出了问题都不知道该怪谁。我自己的经验是设计存储架构之前先把手里的数据按照生命周期分个类方案自然就清晰了。1.1 工业控制器里到底有哪几类数据拿一个典型的运动控制或过程控制设备举例数据大致能分成三类。第一类是运行参数比如 PID 系数、脉冲当量、通信地址、校准零点、报警阈值。这类数据的体量很小从几十字节到几 KB 顶天了但是改动频繁——调试的时候一天改几十次很正常而且每一项都直接关系到设备能不能干活。这类数据的核心诉求是掉电立刻保住、单字节原子写入、足够长的擦写寿命。第二类是固件和系统关键信息包括 Bootloader 备份、应用程序镜像、FPGA 配置文件、出厂校准表。这类数据往往是几千 KB 到几 MB 级别改动的频率极低可能几个月才升级一次但绝不能丢一旦写坏设备就变砖了。它们对存储介质的要求是按扇区快速擦写、数据完整性校验、支持安全升级的备份切换机制。第三类是运行日志和采集记录比如温度曲线、故障记录、通信报文、计件数量。这类数据在掉电前需要尽可能多地保留体量是持续增长的一天几百 KB 到几十 MB 都很正常。日志丢了不致命但客户要追溯故障原因的时候拿不出来就非常被动。这三类数据放到同一种介质里彼此拖后腿。全塞 EEPROM容量不够、日志根本写不下全塞 SD 卡每次上电都要挂载、人力物力都耗不起而且参数写入一个小扇区也要承受文件系统的写放大和磨损全塞 NOR Flash成本高、频繁参数更新会消耗擦除寿命日志量一大也不划算。1.2 分级存储的核心理念让每颗芯片只干它最擅长的事所以我的习惯是把存储硬件拆成三级每级对应上面一类数据层级介质容量典型值适合的数据核心优势主要代价L0EEPROM (I2C)2KB~512KB运行参数、标定值按字节原子写、寿命高达百万次、掉电不丢容量小、总线速率低L1NOR Flash (SPI)8MB~64MB固件镜像、FPGA配置、关键日志归档随机读快、扇区擦写好控制、支持 XIP擦写寿命约10万次、扇区擦除较慢L2SD 卡 (SDIO/SPI)512MB~32GB批量运行日志、历史曲线容量大、即插即用、可离线分析文件系统复杂、掉电与热插拔风险顺着这张表你就能理解标题里STM32FPGA 分级存储的布局意图了STM32 负责业务逻辑和参数管理FPGA 去兜底那些对时序要求高的存储操作比如 NOR Flash 的高速连续写、SD 卡的数据流缓冲。两者各管一道才不会出现MCU 忙于写日志、导致实时控制周期被 stretch这种事情。1.3 在这个方案里 STM32 和 FPGA 各自的分工具体到我的项目里分工是这样的。STM32 独占 EEPROM。参数读写本身是低频操作I2C 总线在 STM32 上处理完全够用没必要让 FPGA 插一脚。MCU 挂了也不至于连参数都读不了。NOR Flash 挂在 FPGA 侧。为什么因为工业控制器有时候需要在控制周期内连续记录高速采集的数据比如振动波形、电流瞬态这类数据吞吐大、实时性强STM32 的 SPI 外设扛不住那么高频的中断写入如果让 MCU 用轮询方式写其他任务就全卡住了。让 FPGA 直接把数据流从 FIFO 灌进 Flash效率和确定性都更高。SD 卡也挂在 FPGA 侧专门用来承接固化后的日志文件流。MCU 只需要通过 FPGA 的转发接口按块提交日志数据文件系统甚至可以在 MCU 侧跑也可以只做裸分区管理。这样 SD 卡读写的大量底层时序、CRC 校验都由 FPGA 逻辑保证不占用 MCU 的 CPU 时间。一句话总结我的设计原则按照谁对实时性要求最高、谁就离 FPGA 最近来分配总线和存储外设。STM32 管好策略FPGA 管好时序存储系统才真正称得上分级。2. EEPROM 这一级参数改错了要能反悔掉电了要能保住先聊 L0 这一级。EEPROM 在工业产品里是参数安全的最后一道底裤。方案里选的是 I2C 接口的 24C 系列比如 AT24C256 或者 Microchip 的 24AA512具体容量视参数表的长度而定。绝大多数控制器几十个参数就够256Kbit 的芯片能写几千字节配置余量充足。2.1 为什么不让 STM32 用内部 Flash 模拟 EEPROM很多项目为了省一颗料直接用 STM32 内部 Flash 模拟 EEPROM。我试过小批量、实验室环境确实能跑但在工业现场我强烈不建议。原因有三条。第一内部 Flash 需要整页擦除再写入不是字节级原子操作如果掉电时机恰好落在擦了一半的时刻整个参数页就全废了。第二写入前要关全局中断写操作期间系统实时性受影响你在中断里改一个参数可能正好把伺服使能的沿给卡掉了。第三Flash 擦写寿命通常只有一万到十万次而参数更新频繁的产品用一两年就可能达到上限一旦超限整颗 MCU 的程序区都跟着遭殃得不偿失。外挂一颗 EEPROM 的成本就几毛钱换来的是字节级原子写、百万次寿命、独立于程序存储的安全性这笔账怎么算都划算。2.2 硬件连接里那几个容易翻车的地方先看管脚连接。24C 系列的 SCL/SDA 分别接 STM32 的 I2C1 对应引脚A0/A1/A2 三个地址脚在单颗使用的时候全部接地地址就是 0xA0。WP 写保护脚是重点很多工程师直接接地等于永远可写我习惯用一个 GPIO 来控制它平时拉高写保护仅在写入参数的前几十毫秒拉低。这样即使软件跑飞也不至于把 EEPROM 内容刷掉。上拉电阻这个细节我要单独拎出来说。I2C 是开漏总线SCL/SDA 必须接上拉。很多人随便选了个 4.7kΩ 就完事但要注意总线速率和总线电容。400kHz 快模式加上几条长走线4.7kΩ 往往拉不起来波形变圆导致通信错误。我一般控制在 1kΩ~2.2kΩ 之间如果 EEPROM 和 MCU 在板内很近、线短2.2kΩ 实测最稳。另外强烈建议在 SCL/SDA 上各串联一个 22Ω 的小电阻放在靠近 MCU 引脚那一端对抑制高速边沿的振铃有奇效。电源去耦也别省EEPROM 是纯数字芯片虽然不至于像模拟器件那样敏感但我见过因为 VCC 纹波太大导致 I2C 写操作偶发失败的案例。芯片旁边的 100nF 电容别省而且电源要先经过磁珠或 RC 滤波再进芯片。2.3 驱动要处理好三个看不见的坑写周期、页边界、应答第一坑24C 系列每次字节写或页写之后内部需要 3~5ms 的写周期 tWR在 tWR 期间芯片不响应任何命令也不产生 ACK。很多人写驱动时发完数据就不管了下一条写指令直接失败。正确的做法是写完一字节或一页后轮询设备地址直到收到 ACK 为止这样既等待了内部写完成也确认了器件活着。第二坑页写跨页边界会自动回卷。24C256 的页大小是 64 字节如果你从地址 0x3F 开始连续写 10 个字节那么地址 0x3F 之后的地址会回卷到 0x00后面的数据全写到页头去了。驱动里必须做跨页拆分我通常写一个按目标页分片写入的函数保证每次调用写入的字节数不超过当前页剩余空间。第三坑硬件 I2C 外设有时会因总线错误进入 BUSY 状态常见的是上电时 SDA 被外部拉低或者通信过程中被干扰。我现在的驱动里每次写操作前先检查 I2C 总线的 BUSY 标志如果异常就复位 I2C 外设和 GPIO避免驱动卡死在等待事件上同时在存储数据里附加 CRC 校验和双份镜像写入时先写备份区、再写主区读取时校验失败自动切换备份区相当于参数区的 RAID 1。2.4 掉电保护策略掉电监测要快、要早、要给 EEPROM 留出时间工业控制器的掉电场景跟开发板不一样不是拔插 USB 这么温和。现场是三相电闸一拉控制电源由输入端的大电容维持几十毫秒然后断崖式下跌。EEPROM 写一个字节需要大约 5ms 的供电保证所以掉电检测必须在电压还没跌到 MCU 最低工作电压之前就触发中断。我的典型做法电源入口处放置一个电阻分压网络检测 24V 直流母线电压当它降到 20V 左右时比较器翻转触发 STM32 的一个外部中断。这个中断的优先级设到最高中断里只做一件事把当前需要保存的参数立刻写入 EEPROM然后置标志让主循环停止业务。同时在 STM32 的 VDD 引脚附近加大容量的储能电容保证从检测到掉电到EEPROM 写完期间电源不掉链子。实测 1000μF 的储能电容可以给系统多扛 50ms 以上足够写完一整页参数。这里有个不少人忽略的点FPGA 的配置 RAM 在掉电后内容即失如果你的参数里有涉及 FPGA 的配置项比如编码器方向取反、滤波系数必须记住在掉电保存时把当前生效值和下次上电加载值分开设计。我在参数表里直接规划了生效模式字段有些参数是立即生效加掉电保存有些是仅本次运行生效重启恢复默认。这样既灵活又不会出现灾难性的误写。3. NOR Flash 这一级固件要能升级、配置要安全还要扛住高速采样写入L1 级我选 SPI NOR Flash型号上用 W25Q64 或者国产兼容料居多。容量根据要存的东西定一份 STM32 固件约 1.5MB一份 FPGA bit 文件约 800KB再加一个出厂校准表区域64Mbit8MB的 NOR Flash 非常宽裕。若需要存高速波形数据建议上 128Mbit 甚至更大成本和封装差别都不大。3.1 为什么高速采集数据的落盘放在 FPGA 而不是 MCU这是个架构问题。高速 ADC 采样数据如果走 STM32 的 SPI一次 DMA 搬运都要占用总线采集 1MSPS × 2 字节 × 多通道吞吐量轻松到几十 MbpsMCU 的 CPU 忙不过来还可能影响伺服控制环的实时响应。FPGA 做这事有天然优势内部可以做深度 FIFO接收 ADC 数据流后按扇区缓冲拼装然后以 SPI Master 方式连续写入 NOR Flash。整个写 Flash 的时序由 FPGA 状态机精确控制MCU 完全不需要参与。要读取数据时MCU 给 FPGA 发一个读地址读长度命令FPGA 再按地址把数据吐回来。这样 Flash 读写的带宽压力被 FPGA 隔离掉了CPU 只处理解析后的有效信息。3.2 FPGA 控制 SPI NOR Flash 的时序要点命令序列、状态轮询、页编程NOR Flash 的写入流程是固定的写使能0x06→ 页编程命令0x02→ 地址 → 数据 → 等待 WIP 位清零。在 FPGA 里实现这些命令不难但有几个细节直接影响可靠性。第一个细节是写使能的时序。每次页编程、扇区擦除操作执行之前必须先发写使能命令否则 Flash 会拒绝执行。如果状态机在异常情况下跳转错了状态少发了 0x06后面的操作会静默失败连错误提示都没有。我调试时吃过这个亏后来在状态机里加了检查操作是否真的执行成功的环节。第二个细节是等待操作完成的方式。有很多人习惯固定延时比如擦除一个扇区就 sleep 50ms。但不同品牌、不同批次的 NOR Flash 擦除时间差异很大典型值 50ms最大值可能到 400ms。固定延时要么太保守浪费时间要么太冒进导致操作中途被下一个命令打断。正确做法是轮询读状态寄存器0x05看 WIP 位bit0直到它为 0。这个轮询在 FPGA 里就是一小段循环状态不占 CPU也不用猜时间。第三个细节是页编程的边界。SPI NOR Flash 页大小通常是 256 字节连续写入超过页边界会回卷和 EEPROM 的页回卷机制类似。FPGA 里做写入逻辑时务必将要写的数据按源地址和目的地址双重对齐拆分每次页编程不超过 256 字节并处理好两个页之间跨页封装的地址计算。下面给一个简洁的 Verilog 状态机骨架展示页编程命令的发送流程供参考localparam IDLE 3d0, WE 3d1, PGM_CMD 3d2, PGM_ADDR 3d3, PGM_DATA 3d4, WAIT_WIP 3d5; always (posedge clk) begin case (state) IDLE: if (start_pgm) state WE; WE: state PGM_CMD; // 已拉低CS发送0x06 PGM_CMD: state PGM_ADDR; // 发送0x02并开始送3字节地址 PGM_ADDR: if (addr_done) state PGM_DATA; PGM_DATA: if (byte_sent pgm_len) state WAIT_WIP; WAIT_WIP: if (wip_clear) begin state IDLE; pgm_done 1b1; // 拉高CS完成一次页编程 end endcase end这个状态机里最值得注意的就是 WAIT_WIP拉高 CS、发读状态寄存器命令、读取一个字节、检查 bit0、重复直到清零。忘了这一步你的 Flash 控制器就像个没有刹车系统的车跑得越快死得越快。3.3 固件双备份与掉电变砖的最后一公里防线NOR Flash 不能只规划一个应用区位。工业现场固件升级过程中突然断电是最常见的变砖场景。所以我规划 Flash 分区时永远用一个 Boot 区 两个 App 槽位的方式当前运行的固件在一个槽位升级包写入另一个槽位全部校验成功后再切启动标志。这样即使升级过程中掉电下次上电还是能回退到旧固件设备不至于变成砖。FPGA 的配置也有类似考虑bit 文件存储在 NOR Flash 里FPGA 上电时通过 SPI Slave 或 SelectMAP 方式加载。如果 bit 文件写到一半就断电下次上电 FPGA 加载的就是半个文件轻则管脚毛刺乱飞重则配置失败。所以我在 FPGA 配置文件之前加了个 32 位 CRC 字段FPGA 加载完成后回读校验失败则向 MCU 报告MCU 再从备份槽位重新下发配置。3.4 掉电时 NOR Flash 的写入保护策略NOR Flash 本身有 WP# 引脚和状态寄存器的 BP 位。对于存放 Bootloader 和出厂校准数据的区域我会把状态寄存器的 BP0~BP3 设为写保护防止异常程序把这些区域擦掉。平时正常运行时MCU 不需要往这些区域写数据所以保持写保护状态完全没影响只有进入固件升级模式才临时解锁。掉电检测方面NOR Flash 的高速写流程不像 EEPROM 那么好打断。一个 4KB 扇区擦除正在进行时突然掉电Flash 内部状态机可能停留在中间状态。所以 NOR Flash 区域要有操作日志机制每次写操作开始前先在一个固定的小扇区里记录正在写哪一块、数据 CRC 是多少写完后再标记完成。上电时扫描这个日志如果发现上次操作未完成就回滚或重写保证数据一致性。4. SD 卡这一级日志文件系统与数据流的缓冲与封口L2 级的 SD 卡承担的是大而杂的日志。我见过很多工程师在这一级栽跟头FATFS 挂不上、文件写一半断电、文件系统损坏读不出来。其实 SD 卡在工业环境下的坑一大半来自文件系统协议栈和掉电时序的匹配问题。4.1 挂在 MCU 还是 FPGA 侧我给出的总线分配方案标题里说的是 STM32FPGA 架构所以 SD 卡在逻辑上可以由任何一侧控制。最稳妥也最常见的方案是 SDIO 接口由 STM32 直接驱动因为 STM32 的 SDIO 外设配合 DMA吞吐量足够跑日志。但这样做的代价是 MCU 要承受文件系统的 CPU 开销和中断负担。如果是高通量、高实时性需求比如连续采集电机电流波形并保存到 SD 卡MCU 侧做会很容易挤占控制回路的时间片。所以我的做法是SD 卡物理层仍接 STM32 的 SDIO但数据路径经过 FPGA 的 FIFO 缓冲MCU 只负责按块提交数据和维护 FAT 表。FPGA 在这里起蓄水池的作用当 SD 卡写一个扇区需要几十毫秒时MCU 不会因为这几十毫秒而把控制周期拉长数据先落进 FPGA 的大 FIFOSD 卡忙完再来取。简单说MCU 只关心日志块的起始扇区和长度FPGA 负责把这一块数据流按 SD 卡的时序慢慢推出去。系统看起来既是 MCU 控制 SD 卡又是 FPGA 在扛 SD 卡时序实际上是一个职责分离的协作关系。4.2 FATFS 移植时最容易被忽略的三个配置如果你用的是 FatFS 协议栈下面几个配置直接影响工业场景的可靠性。第一个是_FS_EXFAT。现在市面上很多 SD 卡出厂默认 exFAT 或大容量 FAT32如果你只开了_FS_FAT32插上一张 64GB 的卡直接挂载失败。我在项目里干脆打开 exFAT 支持同时用f_mkfs把卡格式化成 FAT32 或 exFAT避免客户随便插张卡不识别。第二个是_USE_LFN长文件名支持。工业日志文件我习惯按日期命名比如LOG20250101_1.CSV不开长文件名就截断成LOG2025~1.CSV排查问题很不直观。长文件名本身占用较多 RAM但 STM32F4/H7 的资源完全够用。第三个是扇区缓冲。FatFS 默认_MAX_SS是 512但现在很多 SD 卡用 4KB 物理扇区。如果 SD 卡报告扇区大小是 4096 而 FatFS 还用 512 读写部分卡的兼容性会出问题。保险做法是在diskio.c里对CTRL_GET_SECTOR_SIZE正确响应并让 FatFS 的缓冲区对齐到 4 字节以上。我踩过这个坑现象就是偶尔写文件死循环——排查了一下午最终发现是 DMA 缓冲地址没对齐到 4 字节边界。4.3 日志文件的封口设计掉电后不会留下一堆损坏文件最让我头疼的问题曾经是现场拉闸后再上电看 SD 卡最近的日志文件要么是 0 字节要么 FAT 表里记录的大小与实际数据完全对不上。原因是文件系统在写入数据后并没有同步更新目录项里的大小字段掉电那一刻刚好停在数据已写、目录未更新的窗口期。解决办法是主动封口。我的日志系统是这样设计的MCU 每写完一整块日志数据立即调用f_sync或f_write后立刻f_truncate再f_lseek更新文件大小保证关键扇区及时回写。这个操作频率很低不会成为性能瓶颈但能把掉电损坏的概率降到原来的十分之一以下。更进一步我维护一个当前日志状态文件里面只存三行字当前日志文件名、最新写入扇区、最近一次同步时间。每次f_sync时顺手更新这个状态文件。掉电重启后MCU 读取状态文件就能快速定位到上次写到哪个位置跳过损坏区段从断点继续。这个设计让日志在恶劣环境下的完整性得到了质的提升。4.4 应对 SD 卡的两个物理脾气热插拔与大电流跌落工业控制器里 SD 卡通常是焊死在板上的 eMMC 或贴片 TF 卡座但也有人为了扩容做成抽屉式卡座。抽屉式问题很大客户在设备运行时拔卡总线上的电流突变可能导致 SDIO 时钟线上的毛刺把主控的 SDIO 外设打死插回一张不同容量的卡文件系统缓存与新卡参数冲突直接挂不上。我的建议是能不热插拔就别热插拔卡座加上卡检测脚 CD#检测到拔卡立刻通知 MCU 弹出并禁用 SDIO 时钟插入后必须做完整的初始化流程而不是沿用缓存参数。另外在电路上每根 SDIO 数据线、时钟线、命令线都要串联 33Ω 或 47Ω 的排阻电阻要放在靠近主控端能有效抑制走线过长带来的反射。功耗也别忘了。SD 卡写入瞬间的峰值电流可以达到 100~200mA比 NOR Flash 和 EEPROM 高一个量级。如果 3.3V 电源设计余量不足写卡瞬间电压跌落会导致卡内部电压监测复位表现就是偶尔写文件失败、错误码 0x05这类诡异问题。我在这级电源上加了一个 470μF 的电解电容和几个 100nF/1μF 陶瓷电容的组合实测写卡过程电压跌落从 200mV 降到 50mV 以内问题立消。5. STM32 与 FPGA 之间的存储访问协作命令通道、仲裁与一致性分级存储方案里三颗存储芯片不是孤立的它们都通过 STM32FPGA 的协作来服务整个系统。所以这两颗芯片之间的通信架构决定了整个存储体系能不能统一指挥、协同作战。5.1 命令通道用寄存器组还是报文协议我见过不少项目让 STM32 跟 FPGA 之间用一大片并口直接连一堆 GPIO 来传数据结果调试时对着逻辑分析仪头皮发麻。自己定协议虽然灵活但开发和排错成本太高。我的建议是走寄存器访问 轻量报文的方式在 FPGA 里实现一组寄存器映射MCU 通过地址线 数据线 读写信号访问这些寄存器所有跨时钟域的操作都在 FPGA 内部完成同步处理。这个方案的道理和裸机访问外设寄存器一样简单MCU 对存储设备的读写命令实际上是往几个特定寄存器里填内容然后置 start 位FPGA 检测到 start 后自动执行后续操作完成后置 done 位并更新状态寄存器。MCU 只需要轮询状态不需要关心底层的 SPI/SDIO 时序细节。5.2 存储访问的仲裁不能同时让两个总线大师去抢一颗芯片FPGA 里同时存在多个存储访问源ADC 采样的高速写、MCU 的参数读、固件升级通道的写、SD 卡日志的流式转发。如果这些访问不加节制地同时发起SPI 总线和 SDIO 总线会打起来。所以我在 FPGA 内部做了一个小仲裁器类似片上总线。所有存储访问请求都带着优先级标签比如固件备份写 掉电参数保存 参数读 采样日志写 普通日志写。同一时刻只能有一个请求占用对应存储介质的总线其他请求在 FIFO 里排队。这样既保证了掉电时关键操作的及时性又避免了多条总线上的信号竞争。这个仲裁逻辑只有几百行 Verilog但带来的工程意义重大存储访问的确定性得到保证不会因为一次优先级翻转导致采样数据被覆盖。调试时也只需要看一个仲裁状态寄存器就知道当前谁在用 Flash、谁在等 SD 卡。5.3 一致性视角FPGA 写数据MCU 怎么知道自己读到的不是半截MCU 读 FPGA 里缓存的采样数据时如果 FPGA 正在写同一个缓冲区MCU 可能读到半新半旧的数据。这个问题在纯软件层面解决不了必须在硬件层面加同步设计。我习惯用双缓冲乒乓切换FPGA 依次往两个缓冲区写写完一块就切换标志并产生一个中断给 MCUMCU 只读当前非活跃的缓冲区。这样 MCU 永远读不到正在被写入的数据数据完整性天然保证。要做 CRC 校验也可以在每块数据的末尾由 FPGA 追加 32 位校验值MCU 读取后立即验证。这个方案虽然费一点 BRAM 资源也就是几 KB 级别但大大减少了 MCU 与 FPGA 之间的一致性 bug。否则你会在偶尔多读两个字节偶尔读到旧数据这类魔幻问题上耗掉好几个晚上。5.4 掉电瞬间的协作状态机MCU 和 FPGA 要按剧本走处理掉电时MCU 和 FPGA 必须有一个明确的配合时序否则两边同时操作存储介质会产生致命冲突。我的设计是这样掉电检测触发 STM32 外部中断MCU 立刻向 FPGA 发一个紧急冻结请求通过一个专用 GPIO 管脚拉高来传递FPGA 收到冻结请求后停止所有非关键写入操作将当前 FIFO 里剩余的数据尽力写入 NOR Flash完成一个内部优雅停止状态MCU 利用储能电容提供的剩余电量完成 EEPROM 参数保存FPGA 确认写完后通过握手位通知 MCU我已就绪MCU 记录掉电标志到 BKP 寄存器等待电源归零。这套流程总时长控制在 20~30ms 内配合储能电容完全可行。关键是不能让 MCU 和 FPGA 同时写同一片 NOR Flash所以冻结请求的优先级要高于一切存储操作。6. 验证方法与踩坑清单存储系统怎么测才能放心交付代码写完了、板子能跑了不等于存储方案可以交付。我在实际项目中总结了一套验证矩阵专门用来压测存储链路发现过不少平时没事、现场必炸的隐患。6.1 长时间写读循环用高温老炼思路压测每一级存储对 EEPROM我跑的是参数区间反复写读循环全地址随机写、回读比对、掉电中断随机注入。测试程序会自动记录出错地址和出错类型连续跑 24 小时以上。对 NOR Flash重点是扇区擦除后的数据完整性检查以及扇区边界回卷的统一性验证。对 SD 卡我用一份独立的测试固件连续写满卡容量的 30%再完整回读比对中途人为断电多次统计文件损坏率和 FAT 表异常率。这些测试不是软件自测而是板级硬件测试也就是要带着电路板上的实际信号质量一起来测。尤其是 SDIO 总线只有在实际跑数据流时信号完整性问题才会显形。6.2 掉电瞬间注入比看门狗更严格的断电虐机掉电测试的标准做法是让系统正常运行并持续写入存储然后用一个可以设定角度的继电器或固态开关在市电的不同相位随机切断电源循环 2000 次以上。每次掉电后设备重新上电检查 EEPROM 参数、NOR Flash 关键区、SD 卡文件系统是否完好。我遇到过的最隐蔽问题就是在这个测试里暴露的EEPROM 的写保护脚由一个 GPIO 控制掉电瞬间该 GPIO 被释放为高阻上拉电阻没能维持足够快的上升沿导致写保护激活滞后几十微秒。虽然参数最终保住了但那次实际写入是侥幸完成的。后来我改成保护脚默认硬件上拉写入时 MCU 主动拉低从硬件层面兜底风险才彻底消除。还有一个值得注意的现象是反复掉电后NOR Flash 的某个扇区坏块率会显著上升。这不是颗粒质量差而是擦除命令掉电后留下了半擦除状态下一次上电回滚逻辑如果处理不当会把扇区的剩余数据也擦掉。解决方法是优化上电扫描逻辑发现上次操作标记为未完成时先做整扇区重写而不是简单擦除。6.3 现场易发问题的排查清单现象可能原因处理建议I2C 写 EEPROM 偶发无 ACK上拉电阻过大、信号沿过缓减小上拉电阻、加串阻、加大储能电容NOR Flash 写入后回读错误页写跨边界回卷、未轮询 WIP驱动层严格按页拆分写完轮询的代码别优化掉擦除扇区命令总超时擦除期间被更高优先级打断检查 SPI 总线是否被模块间复用必要时加互斥信号量固件升级掉电后无法启动没有双槽位备份机制改成 Boot双 App 槽位升级完成后再切启动标志SD 卡偶尔写文件失败电源跌落、DMA 缓冲未对齐加储能电容、检查 DMA 源地址 4 字节对齐SD 卡日志文件大小为 0掉电时目录项未更新用 f_sync 及时同步维护状态文件做断点续写上电读取参数区数据校验失败双区镜像逻辑未生效确认读校验失败后自动回切备份区并记录错误标志这张表里的每一条都是我交过学费的直接拿去用就行。6.4 写在最后的一点项目心得分级存储做完整个系统的数据安全等级上了一个台阶。但我想强调存储架构从来不是选几颗料、接几根线那么简单它本质上是对设备数据的全生命周期管理把实时性要求、寿命要求、容量要求和可靠性要求拆解到合适的介质上再靠 MCU 和 FPGA 的协作把每一条数据流管理到位。如果你正在做类似的项目我的建议是先花一周时间仔细列出设备产生的所有数据类型给每个类型打上寿命预期、容量预期、实时性预期三个标签再回来对照这篇的架构思路你会发现自己也能设计出一套合理的分级存储方案。具体的电路和代码不是死的思路才是。
