做工业控制器这几年，我最大的感受是：数据存储这件事，看着简单，真正要稳定跑起来，到处是坑。尤其是在 STM32+FPGA 这种异构架构里，数据从哪来、往哪存、掉电怎么保、上电怎么恢复，如果不提前规划好存储层级，后期调试能让你怀疑人生。
这篇是“硬件篇”系列的第 12 篇，咱们把存储方案一次性聊透。核心思路就六个字：分级、分时、分区。具体来说，就是用 EEPROM 存关键参数、用 NOR Flash 存固件和配置镜像、用 SD 卡存历史数据和日志文件，三者各司其职，配合 STM32 和 FPGA 的硬件分工，形成一套完整的工业数据落盘方案。这篇内容适合正在做工业网关、运动控制、数据采集终端的朋友参考，也适合刚把 STM32 和 FPGA 搭到一起、正为“数据怎么存不丢”发愁的同学。
1. 存储分级设计：EEprom、NOR Flash、SD 卡到底各管什么
很多朋友拿到项目第一反应是“数据量大就上 SD 卡，参数少就用 EEPROM”，这样的选择没有错，但它把问题想简单了。工业控制器的存储需求不是单一维度的“容量大小”，而是要同时考虑访问频率、数据重要性、擦写寿命、掉电安全性、离线可分析性这五个维度。
EEPROM 的容量虽然小，一般也就 2Kbit 到 128Kbit，但它的优势是字节级擦写、寿命长（典型 100 万次擦写）、接口简单（I2C 或 SPI），非常适合存“掉电不能丢、但经常要改”的参数类数据。典型场景是设备标定系数、通信地址、波特率配置、报警阈值、运行模式选择、故障计数这些。这类数据的特点是单次数据量小，但修改频繁，而且修改的即时性要求高。
NOR Flash 的定位则完全不同。它的容量通常在 1MB 到 64MB 之间，支持按扇区擦除、按页写入，读取速度快，甚至支持 XIP（片上执行）。在 STM32+FPGA 的系统中，NOR Flash 的第一职责是存固件镜像和 FPGA 配置文件，其次是存“需要快速加载到 RAM 运行的初始化数据”。用通俗的话讲，NOR Flash 是“程序和处理逻辑的仓库”，EPROM 是“现场运行参数的便签本”。
SD 卡的定位就更好理解了——大容量、顺序写入快、文件系统友好、可离线拔插。它的任务集中在历史数据、运行日志、趋势记录、事件追忆、曲线存储这类“量大、低频访问、事后要分析”的数据上。
我经常用一个类比来向同事解释这三者的关系：EEPROM 是设备里的一块白板，用来记当天要用的电话号码；NOR Flash 是书架上的一本书，内容稳定、随时翻阅，但改一次要重印一章；SD 卡是抽屉里的一堆文件夹，什么都能收，但你不能指望它像白板一样随手擦写还不损坏。
从硬件架构上看，STM32 做主控、FPGA 做前端采集和时序控制，存储任务的分配也有讲究。FPGA 侧更适合直接管理高速数据流，比如把高速 ADC 采集的数据通过 DMA 或 FIFO 送到 STM32 的外部 SDRAM 暂存，再由 STM32 决定何时搬运到 SD 卡。而 EEPROM 和 NOR Flash 这类低速器件，直接挂在 STM32 的 I2C/SPI 总线上更合理，这样 FPGA 不用操心低速外设的时序，可以把资源用在真正需要的并行处理上。
2. 核心硬件连接与选型细节：总线怎么接、地址怎么分
2.1 EEPROM 挂在哪个总线上，地址线怎么处理
EEPROM 最常见的接口是 I2C。我见到最多的是 AT24Cxx 系列和 Microchip 的 24AA/24LC 系列。选型时先看两个参数：一个是电压范围，工业现场最好选 1.8V~5.5V 的宽压版本，避免 3.3V 系统上电压波动导致写保护误触发；另一个是页写字节数，AT24C256 的页大小是 64 字节，如果你一次要写 100 字节参数，就得拆成两页，否则跨页写入会直接失败。
硬件连接上有一个常被忽略的坑：I2C 的地址引脚 A0/A1/A2。很多板子把这三个引脚全部接地，导致总线上只能挂一颗 EEPROM，想挂第二颗就冲突了。我做过的一块板卡上留了跳线，A2 可配置高低电平，这样在需要冗余备份参数时，可以挂两颗 EEPROM 互为主备。另外 WP 写保护引脚不要直接接地，最好通过 10K 电阻接高电平或者由 STM32 的 GPIO 控制。原因很直接——上电瞬间如果 STM32 的 I2C 引脚状态不确定，可能误触发对 EEPROM 的写操作，把关键参数冲掉。用 GPIO 控制 WP，可以在完成所有写操作后把 WP 拉高，从硬件层面拦截误写。
I2C 总线的上拉电阻也有讲究。标准模式（100kHz）用 4.7K 没问题，但如果你把速率提高到 400kHz，建议换成 2.2K，否则上升沿太缓，总线通信会时不时出错。这个“时不时”的偶发问题最难排查，因为你很难从逻辑分析仪上抓到稳定的错误波形。我在这上面吃过亏——一批板子中大概 10% 在低温下 I2C 通信失败，最后发现就是上拉电阻偏大加低温影响 IO 驱动能力，换成 2.2K 后批量测试再没出过问题。
2.2 NOR Flash 选 SPI 还是并行，映射地址怎么规划
NOR Flash 的接口分并行和 SPI 两种。在 STM32 系统里，我强烈推荐用 SPI NOR Flash，原因很实际：并行 NOR 虽然读取速度快、支持直接地址映射，但它占用的引脚数量太多，对于已经接了 FPGA 的 STM32 来说，引脚资源非常紧张。SPI NOR 只要 4 根线（CS、CLK、MOSI、MISO），加上 WP 和 HOLD 也就 6 根，把读写速度跑到 50MHz 时，实际吞吐率对固件加载和配置存储来说完全够用。
型号上，工业场景我常用华邦 W25Q64JV 或者 GD25Q64C 这类 SPI NOR Flash，容量 8MB，性价比高，扇区大小 4KB，块大小 64KB。需要注意的是，不同厂商的 SPI NOR 指令集虽然基本兼容 JEDEC 标准，但个别指令（比如进入/退出四地址模式）有差异。代码里要把 Read ID（0x9F）读回来，根据厂商 ID 做差异处理，不要假设所有片子都一样。这一点在换料时特别重要，有一次我把 W25Q64 换成 GD25Q64，结果批量生产后有 3% 的板子读取固件失败，排查到最终原因是 GD 片子的 tCLQV（时钟低到数据输出有效时间）和 W25Q 有细微差异，在高频下时序裕量不够。
地址映射方面，我习惯在 STM32 端这样划分 NOR Flash 空间：
| 区域 | 地址范围 | 内容 |
|---|---|---|
| Bootloader | 0x000000 - 0x00FFFF | 启动引导程序 |
| App 固件区 A | 0x010000 - 0x07FFFF | 主程序镜像（可回滚） |
| App 固件区 B | 0x080000 - 0x0FFFFF | 备用程序镜像 |
| FPGA 配置区 | 0x100000 - 0x13FFFF | FPGA bin 文件 |
| 参数镜像区 | 0x140000 - 0x14FFFF | EEPROM 数据冗余备份 |
| 文件系统区 | 0x150000 - 0xFFFFFF | 文件系统数据区 |
为什么要把参数镜像区单独划一块？因为工业控制器最怕“EEPROM 坏了参数全丢”，EEPROM 本身也有写穿和位翻转的概率，定期把 EEPROM 的内容备份到 NOR Flash 的专用区域，相当于给参数区做了一个影子副本。上电时先比较两者的 CRC，不一致就自动从 NOR Flash 恢复，这个机制在批量设备维护中省了我无数跑现场的精力。
2.3 SD 卡用 SPI 还是 SDIO，供电和电平怎么处理
SD 卡在 STM32 上有两种接法：SDIO 和 SPI。SDIO 的读写速度高，能跑到 48MHz 甚至更高，适合连续记录高速采集数据；SPI 模式速度一般上限 25MHz，但接线简单，占用引脚少。我的建议是：如果你的 STM32 型号有 SDIO 外设，优先 SDIO；没有的话 SPI 模式也能用，但要注意降低写入频率和块大小，避免长时间大数据写入触发卡内部磨损均衡导致的一次性卡顿。
硬件上容易忽略的是 SD 卡供电。很多开发板直接把 3.3V 接到卡座 VDD，这在实验环境没问题，但工业现场电压波动大，3.3V 跌落时 SD 卡会静默损坏文件系统。稳妥的做法是给卡座单独加一个电源开关（比如用 P-MOS 管），由 STM32 GPIO 控制，在插入检测有效后才上电，在掉电检测触发时先禁止写入再断电。另外，SD 卡座要有卡检测开关（CD 引脚），不要省这个引脚，它不只是方便你看“有没有插卡”，更重要的是配合电源控制实现“热插拔保护”。
还有一个细节很多人不知道：SD 卡走 SPI 模式时，MISO 引脚需要外部上拉电阻。因为 SD 卡在 SPI 模式下是推挽输出，但在上电初始化和没有 CS 选通时是开漏状态，不上拉的话，初始化命令可能无法正确返回响应。这个上拉电阻通常 10K 就够了，但有少数卡需要更小的阻值才能稳定初始化，建议直接用 4.7K。
3. 实操过程：STM32 侧驱动编写与 FPGA 侧数据衔接
3.1 I2C EEPROM 驱动的几个关键帧格式
I2C EEPROM 的驱动并不难，难在写完整、读完整。先说页写。AT24C256 页写一次最多 64 字节，如果数据跨页，必须拆开写。问题在于 STM32 的 HAL 库 I2C 传输函数在连续写时不会自动处理页边界，你必须自己计算当前地址到页末尾还剩多少字节，然后分段调用。很多工程师第一次调 EEPROM 写长得像个大数组的数据时会发现数据错乱，原因就是跨页。
我封装了一个比较稳妥的接口，核心逻辑如下：
/* 写入 len 字节，自动处理页边界 */ HAL_StatusTypeDef EEPROM_WritePageSafe(uint16_t devAddr, uint16_t memAddr, uint8_t *buf, uint16_t len) { uint16_t pageSize = 64; /* AT24C256 页大小 */ uint16_t offset = 0; while (offset < len) { uint16_t curAddr = memAddr + offset; uint16_t pageLeft = pageSize - (curAddr % pageSize); uint16_t chunk = (len - offset > pageLeft) ? pageLeft : (len - offset); if (HAL_I2C_Mem_Write(&hi2c1, devAddr, curAddr, I2C_MEMADD_SIZE_16BIT, buf + offset, chunk, 100) != HAL_OK) return HAL_ERROR; /* 等待内部写周期完成 */ HAL_Delay(5); offset += chunk; } return HAL_OK; }写完一定要等写周期完成再读，EEPROM 内部写完需要 5ms 左右（具体看数据手册），如果连续写不等待，后面的写命令会被丢掉。我用的方案是写完每一页后延时 5ms，而不是只在最后延时，这样虽然多花了一点时间，但保证了数据完整。
读操作方面，顺序读取时要注意 STM32 的 I2C 在最后一个字节时要用 NACK 结束传输，HAL 库的 Mem_Read 函数会自动处理，没有问题。关键是多字节随机读时，地址寄存器的发送方式要在子地址 16 位模式下注意高低字节顺序——ST 的 HAL 库用 I2C_MEMADD_SIZE_16BIT 时会自动按高字节在前发送，但如果用的是寄存器级操作，很容易搞反。
3.2 SPI NOR 驱动的扇区擦除与写入策略
NOR Flash 的操作比 EEPROM 稍微复杂，因为它的最小擦除单元是扇区（通常 4KB），写入最小单位是页（通常 256 字节）。你不能单独改某一个字节，要改就必须先把整个扇区擦掉再写回，这是 NOR Flash 的物理特性决定的。
我在工程上用一个“读-改-写”策略来处理参数更新：
- 先把要修改的扇区全部读入 STM32 的 RAM（4KB 没问题，F4 系列有 128KB+ RAM）。
- 在 RAM 中修改对应位置的字节。
- 发出扇区擦除命令（0x20 + 地址）。
- 等待擦除完成（轮询状态寄存器中的 BUSY 位）。
- 按页写入（0x02 + 地址），一次写 256 字节，写完轮询 BUSY。
- 读回整个扇区，计算 CRC，与 RAM 中的数据比对。
这套流程的好处是可靠，代价是速度慢——改一个字节也要 4KB 擦除加 4KB 写回。但工业控制器的配置更新频率不高，花几百毫秒换一个稳定的参数存储是值得的。如果你需要频繁更新，那就应该用文件系统管理 NOR Flash，把参数放文件里，每次只擦文件占用的那几个扇区。
有个细节值得一提：SPI NOR 在擦除和写入操作期间，如果 CS 拉高太快，芯片可能没有正确锁存命令。所以要在发送完命令后保持 CS 拉低，通过读取状态寄存器（0x05）的 BUSY 位来确认完成，而不是盲延时。当然你可以在命令发送后拉高 CS，再重新拉低去读状态，这是标准做法，但有些国产片子在擦除命令刚发完立刻拉高 CS 会收不到命令，稳妥起见加 5us 延时再操作。
3.3 SD 卡文件写入的关键流程与 FatFs 集成
SD 卡的文件级写入，我直接用的 FatFs 开源库，同时把底层移植到 SDIO 或者 SPI 接口上。FatFs 本身的移植不算复杂，但要稳定运行在工业场景，有几个点必须做好。
第一个是磁盘挂载后的格式检查。如果 SD 卡上电后第一次 mount 失败，不要直接报错误，尝试用 f_mkfs 重新格式化，如果格式化也失败，再上报“存储介质损坏”。这样做是应对一些 SD 卡因为异常断电导致 FAT 表损坏的情况，重新格式化后还能继续用，而不是直接判死。
第二个是写入缓冲区的对齐。FatFs 在写文件时，底层需要按扇区（512 字节）对齐写入。如果你的数据缓冲区不是 512 的整数倍，FatFs 会做一次读-改-写，速度会下降很多。我通常是定义一个 512 字节对齐的静态缓冲区，数据拼满一个扇区再写，这样既快又避免频繁卷积到 FatFs 内部逻辑。
第三个是掉电保护。工业控制器最怕写着写着掉电，导致 FAT 表损坏。我的做法是在每次写完一批数据后调用 f_sync，把文件缓冲刷到 SD 卡，而不是依赖 f_close。f_close 在系统异常复位时根本执行不到，f_sync 则可以在每批数据写完后主动调用。配合上电检测电路（STM32 的 PVD 外部中断），在掉电瞬间快速调用 f_sync 并拉高 WP 引脚，把数据损坏概率降到最低。
/* 每批数据写入后同步 */ void SD_LogData(uint8_t *buf, uint16_t len) { FIL file; FRESULT res; res = f_open(&file, "0:/history.dat", FA_OPEN_ALWAYS | FA_WRITE); if (res != FR_OK) return; f_lseek(&file, f_size(&file)); UINT written = 0; res = f_write(&file, buf, len, &written); if (res == FR_OK) f_sync(&file); /* 关键：写完就刷盘 */ f_close(&file); }3.4 FPGA 侧数据采集到存储的流向设计
FPGA 在存储链路中扮演的是“数据生产者”和“数据搬运工”的角色。以我做过的一个 8 通道高速 ADC 采集项目为例，FPGA 负责 ADC 的时序控制、数据采样和 FIR 滤波，然后把处理后的数据通过片内 FIFO 以 16 位并行总线送到 STM32 的 FSMC 接口。STM32 侧用 DMA 接收，数据到一定量（比如 4KB）就打包写入 SD 卡。
这里的核心设计是“乒乓缓存”和“水位线中断”。FPGA 内部设置两个缓冲块，采集数据轮换写入，当一个缓冲块写满后，向 STM32 发中断请求，STM32 通过 FSMC 快速读取这一块数据。这个机制可以避免 FPGA 和 STM32 互相等待导致的数据覆盖。关键参数有两个：缓冲区大小和中断触发阈值。缓冲区大小的选择要结合 STM32 的 DMA 带宽和 SD 卡写入速度。以 SDIO 模式为例，连续写 SD 卡的实测速度约 10MB/s，远高于 ADC 的采样速率的话，缓冲区 4KB 完全够用。
FPGA 采集的数据流如果对时序要求高，还涉及跨时钟域处理。ADC 的输出时钟和 FIFO 读时钟不是同一个域，FIFO 本身解决了这个问题，但你做仿真时一定要用异步 FIFO 的模型，不要用同步 FIFO 代替。我之前就因为偷懒在仿真里用了同步 FIFO，结果上板后发现偶发数据错位，排查了两天才想起来是跨时钟域问题。
FPGA 配置文件的加载路径
还有一个容易忽略的存储功能：FPGA 的配置文件存放。工业设备希望上电后 STM32 自动从 NOR Flash 读取 FPGA bin 文件，再通过 SelectMAP 或 SPI 接口配置 FPGA，而不是依赖 JTAG 在线下载器。这样设备在现场断电重启后才不用专人去烧录。
具体流程是：STM32 启动后，先读 NOR Flash 的 FPGA 配置区，校验 CRC，然后把数据分包通过 FPGA 的配置接口写入。如果 FPGA 配置失败，STM32 回读错误状态，并且尝试从备份区加载第二份配置。这个双备份机制配合前面提到的 NOR Flash 区域划分，是我在做批量设备时觉得最稳妥的方案。
4. 常见问题与故障排查：我在现场踩过的那些坑
4.1 EEPROM 数据偶尔丢失或变为 0xFF
这类问题出现频率最高，多数情况下不是芯片坏了，而是写时序或电源问题。我的排查路径是这样的：
先看 WP 引脚的电位。如果 WP 悬空或者上拉电阻没焊，芯片处于写保护状态，写入失败但读取正常，表现为“看起来配置保存了，重启后突然丢了”。用示波器量 WP 引脚，确认在写操作期间为低电平。
再看电源。EEPROM 的 VCC 如果有较大纹波，写周期可能被干扰。示波器带宽限制 20MHz 看 VCC 纹波，超过 100mV 就要加滤波电容，我一般在 EEPROM 电源引脚旁边放 0.1uF + 10uF 两个电容，并联稳压管最好也加一个，别省。
最后看软件。确认有没有在写 EEPROM 期间被中断函数打断。比如 STM32 的 SysTick 中断里如果有 I2C 操作或者长延时，就会破坏 I2C 时序。我的建议是，I2C 读写 EEPROM 的代码跑在非中断上下文，或者用互斥信号量保护，避免和中断处理函数交叉。
4.2 NOR Flash 里的固件偶尔加载失败
SPI NOR 加载固件失败，我遇到过的原因无非三类：时钟太快导致时序裕量不足、CRC 校验算法不一致、读取地址越界。
时钟问题最隐蔽。我曾经在 STM32F405 上用 SPI2 以 42MHz 读 W25Q64，在 25℃ 环境下稳定运行，但设备放到户外 40℃ 高温箱里测试时，偶尔出现固件加载失败。后来查了 W25Q64 的数据手册，发现在高温条件下，芯片的最大读取频率会下降，42MHz 超出了它的绝对最大额定值。解决方法是把 SPI 分频调到 21MHz，高温问题立刻消失。
CRC 校验不一致问题，一般发生在 Bootloader 和 App 分开开发的时候。Bootloader 生成固件镜像的 CRC 时用的初始值、多项式，和 App 校验时不一致，导致每次升级后重启都报校验失败。我把 CRC 计算函数收敛到一个共用库，Bootloader 和 App 都编译同一个源文件，问题就再没出现过。
4.3 SD 卡拔插后文件系统挂载失败或数据不完整
SD 卡最怕的工作状态就是“写入中拔出”或“写入中掉电”。FatFs 的挂载失败信息往往比较笼统，看到 f_mount 返回 FR_NO_FILESYSTEM，不能马上认为是卡坏了。我的标准排查步骤是：
先用读卡器把卡插电脑上，查看分区表是否还能识别。如果能识别但文件打不开，多半是 FAT 表损坏，用电脑的 chkdsk 修复后重新插回设备，用 f_mkfs 重新格式化。如果设备频繁出现 FAT 损坏，本质问题不是“卡质量差”，而是写入策略没有做掉电保护。应该在硬件上加掉电检测，在软件上加入卡检测中断并定期 f_sync。
数据不完整的问题则要看写入粒度。如果一条记录是 200 字节，你每条 f_write 之后都 f_sync，SD 卡的寿命会急剧下降，且写入速度极慢。我的折中方案是：每攒够 4KB（8 个扇区）或者时间到 1 秒才做一次 f_sync，这样掉电最多丢最后 1 秒的数据，对工业历史记录来说完全可接受。
4.4 数据一致性校验：跨介质备份怎么保证最终一致
EEPROM、NOR Flash、SD 卡三个存储介质各自独立工作，但很多工业应用需要它们保持逻辑上的数据一致性。我常用的手段是版本号加 CRC 的双重校验：
每条关键参数记录里都带一个数据版本号，每次修改 EEPROM 的同时，更新 NOR Flash 里的镜像数据版本号，并把新的 CRC 写进记录头。上电或复位后，STM32 依次读取 EEPROM 和 NOR Flash 中的版本号，直接比较：
- 版本号一致，且 CRC 校验通过，说明数据正常。
- 版本号不一致，以版本号高的为准，将高版本数据回写到低版本介质。
- 两边版本号一致但 CRC 不一致，说明有一份在写入过程中损坏。此时如果 EEPROM 的 CRC 正常，以 EEPROM 为准，并重写 NOR 镜像；如果两份 CRC 都不正常，则进入出厂默认值模式，并置位“配置丢失”报警。
这套逻辑写起来并不复杂，但能把“存储异常导致设备参数漂移”这类工业现场最不愿意看到的问题，从“偶发”变成“可感知、可自动修复”。
5. 工程落地建议：从原理图到量产的几个关键教训
最后再说几个我踩过很多次之后才总结出来的工程建议，这些内容在芯片数据手册里基本找不到，但每一个都直接影响现场可靠性。
第一，原理图阶段就要考虑地平面完整性。EEPROM、NOR Flash、SD 卡都涉及数字信号，SPI 时钟频率一旦超过 20MHz，信号质量对地平面非常敏感。PCB 设计时，这些存储器件下方尽量不要走其他高速信号线，SD 卡座附近更不要放开关电源的电感，否则读写时容易偶发数据错误，调试极难复现。
第二，批量生产测试环节，一定要加存储器的全功能测试。很多板卡出厂测试只测“能不能读”，不测“能不能写、写了能不能保住”。批量产品里偶尔会混入焊接不良的 Flash 或 EEPROM，如果只在装整机后才暴露，返修成本成倍增加。我建议的出厂测试流程是：对 EEPROM 写入特征值并回读比对，对 NOR Flash 做至少一个扇区的擦写循环并校验，对 SD 卡写 1MB 随机数据再读回比对。
第三，预留日志跟踪接口。工业控制器的存储问题往往不是“坏了”这么简单，而是“偶尔出错、原因不明”。如果板卡上有预留调试串口，可以在驱动层加一个存储事件日志，把所有存储操作的返回值、错误码、重试次数记录在 RAM 里，出问题时通过串口导出。有了这些微观层面的数据，你在现场才不用靠猜来排查问题。
坦白说，这套分级存储方案不是最优的，也不是唯一正确的。如果你的设备数据量不大，可能一个 16MB 的 SPI NOR Flash 加文件系统就能搞定；如果你的设备对数据实时性要求极高，可能要走 EMMC 甚至 SSD 方案。但就“通用工业控制器”这个场景而言，EEPROM 管参数、NOR Flash 管固件、SD 卡管历史数据的组合，是我这几年做过最多、也最省心的架构。硬件上没有银弹，但把每种存储用在它最擅长的地方，至少能让你的设备在现场少给你打几通电话。
