STM32+FPGA工业控制器分级存储设计：EEPROM/NOR Flash/SD卡实战

做工业控制器这一行，数据存储永远是个绕不开的“脏活累活”。最近把手里一套基于 STM32+FPGA 架构的控制器存储方案重新梳理了一遍，从 EEPROM 到 NOR Flash 再到 SD 卡，做了完整的分级落地。这一篇是“硬件篇”的第 12 期，专门聊聊这套分级存储是怎么设计、怎么选型、怎么把每个环节调稳的。

先交代一下背景：这套系统里，STM32 跑应用逻辑和通信协议栈，FPGA 负责高速采集和实时控制。FPGA 侧产生的高频数据（比如编码器计数、ADC 采样、IO 状态快照）不能全丢给 STM32 去存，STM32 的 Flash 也不适合频繁擦写；真正需要掉电保存的关键参数又用不上大容量存储。这种“冷热不均、频次不一、容量跨度大”的数据特征，恰恰是分级存储的典型适用场景。

如果你正在做类似的嵌入式控制器，或者正准备在 STM32+FPGA 的双芯方案里塞一套存储系统，这篇内容应该能帮你省掉不少自己踩坑的时间。我会把每一级存储的选型逻辑、硬件连法、驱动实现、掉电保护策略，以及最常见的几个故障排查过程都摊开来讲。

1. 项目整体设计与需求拆解

1.1 三类数据的存储特征

设计分级存储之前，先得把手里的数据按“温度”分个类。我习惯把工业控制器里的数据分成三档：第一档是“极冷数据”，比如设备序列号、校准系数、MAC 地址、PID 参数、开机次数——这些数据一年也改不了几次，但改了必须立刻掉电保存，且不能因为写入中途掉电而损坏；第二档是“温数据”，比如最近一个月的运行曲线、报警记录、工艺参数组别、操作日志，写入频率大概分钟级或小时级，需要按块擦写、按索引读取；第三档是“热数据”，比如高速采样的原始波形、连续几十小时的实时趋势记录，这类数据写入频率极高、单条数据量大，必须按流式写、按时间戳查询。

这三档数据对应的体积也完全不是一个量级：极冷数据通常几十字节到几KB，温数据几百KB到几MB，热数据动辄几十MB甚至上百GB。用单一存储介质硬扛这三档数据，不是浪费就是不够，这正是分级存储的出发点。

1.2 为什么选 EEPROM、NOR Flash、SD 卡这三兄弟

选型的时候不是看谁新、谁快，而是看谁的“写入粒度、擦写寿命、掉电安全、成本”匹配哪一档数据。

• EEPROM：按字节擦写，寿命普遍在 100 万次以上，写入时间毫秒级，掉电保护容易做，适合放校准参数和序列号。虽然容量小（常见 2Kb~256Kb），但冷数据本来就不大。
• NOR Flash：按扇区擦除（典型 4KB），按字节或页编程，寿命通常标称 10 万次擦写。支持 XIP 直接映射执行，读取快，放固件、工艺参数组、报警历史这种“中频中量”数据非常合适。
• SD 卡：以块为单位读写，有文件系统加持，容量大、便宜，适合放采样数据、日志归档这类大批量流式数据。SD 卡的寿命和可靠性天然不如 Flash 芯片，但它胜在可更换、易导出。

这套方案的容量和用途配合如下表：

硬件篇的核心思路就是把“写什么数据”和“用谁去写”彻底分开。STM32 管 EEPROM 和 NOR Flash 这两个“小而关键”的区域，FPGA 管 SD 卡的高速数据流。为什么这么分？因为 SD 卡的块写入和 FAT16/32 文件系统操作如果全压在 STM32 上，主控频繁进中断、腾 DPRAM 缓冲区，实时性就废了；而高频采集数据恰恰从 FPGA 侧过来，让 FPGA 直接写 SD 卡能省一次跨芯传输。

1.3 存储架构图（文字版）

整套存储路径是这样的：

• FPGA 内部逻辑产生的采样数据 → FPGA 侧 SDIO 控制器 → SD 卡（热数据流）
• STM32 下发参数/配置 → STM32 驱动 NOR Flash → 参数组、报警历史（温数据）
• 生产标定/上电加载 → STM32 驱动 EEPROM → 序列号、校准系数（冷数据）
• STM32 与 FPGA 之间通过 SPI 从机接口通信，FPGA 把需要记录的波形数据“推到”STM32 再转存 NOR Flash，或者直接由 FPGA 写 SD 卡；STM32 则从 FPGA 读取状态，把控制参数写入 NOR/EEPROM。

这样设计的好处是：STM32 的 Flash（内部）几乎不做频繁写操作，只用来跑代码；MCU 侧只负责低频、高可靠的数据管理，把高频操作分流到 FPGA 侧。后面我会逐个讲实现细节。

2. 核心细节解析与实操要点

2.1 EEPROM 驱动的三个关键点

EEPROM 是整套存储系统里最“皮实”但也最容易大意的一环。很多人觉得 I2C 读写 EEPROM 太基础了，随便写写就行，实际在工业现场最容易出问题的反而是这颗小芯片。

第一个关键点是写周期等待。EEPROM 写入不是瞬间完成的，AT24C256 这类芯片单字节写周期大约 5ms，页写（page write）虽然能一次写 64 字节，但内部仍然是逐个字节编程。写入之后如果立刻发下一个命令，芯片会不响应。驱动里必须在每次写操作后等待 ACK 轮询（也叫“写周期轮询”）。我见过太多人写完 EEPROM 不延时，导致读出来的数据是旧的，排查半天找不到原因。

第二个关键点是页写跨页边界。AT24C256 的页大小是 64 字节，页写的时候地址会自动回绕（roll over）到本页起始。如果要写的数据跨了页边界，必须拆成两次页写。驱动里的处理逻辑很简单：先算出当前页剩余字节数，取两者较小值作为本次写入长度，写完再更新地址和剩余长度，循环完成整个 buffer 的写入。

第三个关键点是字节地址判断。AT24C256 的寻址是 16 位地址，分高 8 位和低 8 位，I2C 从机地址是 0xA0。很多人拿 AT24C02（8 位地址）的驱动改过来用，高位地址没写对，数据就全部错位了。

附上一段实际可用的 AT24C256 页写核心代码（基于 STM32 HAL 库）：

uint8_t eeprom_write_page(uint16_t addr, uint8_t *buf, uint16_t len) { uint16_t page_size = 64; uint16_t page_offset = addr % page_size; uint16_t chunk = page_size - page_offset; if (chunk > len) chunk = len; HAL_I2C_Mem_Write(&hi2c1, 0xA0, addr, I2C_MEMADD_SIZE_16BIT, buf, chunk, 100); eeprom_wait_ready(); // ACK 轮询，等待内部写周期结束 if (chunk < len) { HAL_I2C_Mem_Write(&hi2c1, 0xA0, addr + chunk, I2C_MEMADD_SIZE_16BIT, buf + chunk, len - chunk, 100); eeprom_wait_ready(); } return 0; }

eeprom_wait_ready()的实现就是循环发起始条件 + 从机地址，直到收到 ACK 为止。这段代码看着简单，但在产线上跑了两年没出过一例 EEPROM 数据损坏。

2.2 NOR Flash 的分区设计与双备份策略

NOR Flash 的驱动大家用得最多的是 W25Q64/128/256 系列。SPI 接口，指令集统一，几乎不用改驱动。这一级存储要解决的核心问题是：参数区写入频率虽然不高，但一旦在擦除过程中掉电，整个扇区就废了，直接影响设备启动。

我的设计思路是把 Flash 分成三个区域：启动参数区（Boot Parameters）、工艺参数区（Recipe Area）、报警/日志区（Log Area）。其中启动参数区和工艺参数区都做双备份。也就是说，同一份参数存两份，分别放在不同扇区，写入的时候先写备份区，再写主用区；读取的时候先读主用区，如果校验失败（比如 CRC 不对），自动回退读备份区。

为什么拆成双区而不是三区？因为对 NOR Flash 来说，擦除次数是有限资源（W25Q 系列典型 10 万次擦写周期）。双备份已经把可靠性翻倍了，三备份就浪费了容量和擦写寿命。

具体分区我一般这样算：

W25Q64 总容量 8MB。我给启动参数区分配 4 个扇区（每个扇区 4KB，共 16KB），工艺参数区分配 16 个扇区（64KB），报警日志区分配 256 个扇区（1MB），剩余空间留作固件升级暂存和扩展。这个分配比例不是拍脑袋定的，而是通过对设备 3 个月运行数据的统计得出的：报警记录平均每天 200 条，每条 64 字节，1MB 大概能存 8000 条，撑一个月没问题，配合 SD 卡上的历史归档，正好形成“Flash 存近期、SD 存归档”的接力。

2.3 SD 卡写入的“避死锁”设计

SD 卡这一级看起来最“简单”——不就是 SPI/SDIO + FATFS 吗？实际上坑最多。FPGA 写 SD 卡不能像 STM32 那样频繁调用文件系统 API，因为文件系统的目录项更新、FAT 表更新、簇分配这些操作都有“先写后擦”的顺序依赖，中途掉电很容易导致文件系统损坏。

我这边用的是一个比较“笨”但极其稳定的做法：固定文件名 + 追加写模式。FPGA 侧每次开机创建一个新文件，例如REC_20250101_000000.DAT，之后纯追加写入，写满一个簇再写下一个簇。不让 FPGA 做任何“删除文件”“创建目录”“修改文件大小”之类的操作，把 FATFS 的复杂逻辑全部屏蔽在 STM32 侧。

具体实现上，FPGA 内部会维护一个“写入指针”和“当前簇号”，每次写数据前先检查当前簇剩余空间，不够了才申请新簇。这样一次 SD 卡写入只涉及两个操作：数据区块写入 + FAT 表更新。数据区块写入失败可以重试，FAT 表更新失败就触发“写保护”状态，把 FPGA 的采样数据先暂存到内部 BRAM 或 DPRAM，等 SD 卡恢复正常再回写。

这里最容易被忽视的是 SD 卡的总线宽度和时钟频率匹配。FPGA 侧用 SDIO 4-bit 模式时，SD 卡内部擦写操作会拉低 SDIO 的时钟线（busy 信号），FPGA 必须处理这个 busy 等待，否则直接发起下一笔写命令就会超时。好的做法是在 FPGA 的 SDIO 控制器里做一个“命令超时重试”状态机，超时后重新发送 CMD13 查询卡状态，等卡空闲后再继续。

2.4 STM32 与 FPGA 的分工边界

这套方案里有个很容易犯的认知错误：“STM32 是主，FPGA 是从”，所以所有数据都应该经 STM32 中转。但其实高频数据流如果全走 STM32，MCU 的中断负载和 DMA 占用会非常高，而且 STM32 内部 SRAM 有限，大块波形数据根本放不下。

我最终确定的边界是：

• 控制链路：STM32 下发控制字 → FPGA 执行 → FPGA 回传状态。频次高、数据短，走 SPI 从机寄存器，由 STM32 轮询或中断读取。
• 记录链路：FPGA 侧直接采集、直接写 SD 卡，STM32 只负责初始化（挂载 FATFS、创建文件）和周期性的状态同步。STM32 不再参与高频数据的搬运。
• 配置链路：STM32 通过 SPI 读 EEPROM/NOR Flash，把参数写进 FPGA 内部的寄存器组；FPGA 侧不直接访问 EEPROM/NOR Flash，避免跨芯争抢 I2C/SPI 总线。

这样分工的好处一是实时性有保障，二是让两边的存储职责互不干扰。FPGA 挂 SD 卡挂了不影响 STM32 读参数；STM32 写 NOR Flash 的时候 FPGA 照样录数据，互不阻塞。

3. 实操过程与关键环节实现

3.1 硬件连接与引脚规划

先看硬件连接。因为这块板子的空间有限，我尽量复用了 STM32 的 SPI 外设。

• EEPROM（AT24C256）接在 STM32 的 I2C1：SCL 对应 PB6，SDA 对应 PB7。上拉电阻用 4.7k，靠近芯片放置。
• NOR Flash（W25Q64）接在 STM32 的 SPI1：CS 用 PA4（软件控制），SCK 用 PA5，MISO 用 PA6，MOSI 用 PA7。SPI1 时钟设 18MHz。
• SD 卡接在 FPGA 的 SDIO 接口（4-bit 模式），CLK 约 25MHz，CMD/Data0~Data3 分配在 FPGA 的专用引脚上。这里 FPGA 内部要做一个简单的电平转换接口，因为 FPGA 的 IO bank 电压和 SD 卡 VDD 可能不一致（我用的是 3.3V 和 3.3V 对接，省了电平转换芯片）。

需要注意 Flash 的 WP（写保护）引脚不能悬空。W25Q 系列的 WP 引脚内部默认是“上拉灭能”，如果悬空可能导致意外写保护或者误触发。我直接把它用 10k 电阻拉高，并在 PCB 上预留了跳线，方便产线上临时解锁写保护。

3.2 初始化顺序：先 EEPROM，再 NOR Flash，最后 SD 卡

系统上电后的初始化顺序，我自己踩过一个坑之后才总结出这个“三步走”：

第一步，先初始化 I2C 和 EEPROM，读取设备序列号和出厂校准系数。这一步必须放在最前面，因为后面所有参数组的有效性判断都要依赖序列号做关联。如果 EEPROM 读出来 CRC 校验错误，系统会进入“出厂默认参数”模式，并在运行日志里标记一条“参数复位事件”。

第二步，初始化 SPI 和 NOR Flash，读取工艺参数主区。这里要注意一个容易忽略的点：NOR Flash 读取不需要等内部写周期，但上电后第一次读状态寄存器（Read Status Register-1）最好做一次“软复位”指令（0x66 + 0x99），让 Flash 退出可能的异常状态。我遇到过一块 Flash 上电后 BUSY 位一直为 1 的情况，软复位指令发完就好了。

第三步，初始化 FPGA 侧的 SD 卡。FPGA 内部有一个独立的 SD 卡初始化状态机，上电后先执行 SD 卡复位（CMD0）、获取 CID（CMD2）、设置块长度（CMD16），然后进入 4-bit 模式。STM32 只负责告诉 FPGA“可以开始录了”，具体初始化时序由 FPGA 自己掌控。

整个初始化过程要求在 1.5 秒内完成，因为我这套控制器的上位机协议规定设备上电后 2 秒内必须回应“就绪”指令。

3.3 NOR Flash 写入流程与掉电安全

NOR Flash 写入一个参数组的标准流程如下：

1. 计算参数组的 CRC32 和长度，写入一个 64 字节的头部结构。
2. 从主用区找一块空扇区，没有空扇区就选“最旧”的扇区擦除。
3. 先把参数写入备份区（先写目标扇区的数据，等待空闲后擦除另一个扇区，再写入）。
4. 写完后读回整个扇区内容，比对 CRC32 是否一致。
5. 一致则更新主用区标记（在扇区头写入 Magic Number），完成。
6. 如果不一致，再写一次备份区；连续两次失败，则报警提示“参数区损坏”。

实际代码里还会做“写后回读”的联动校验，不是只读几个字节，而是全扇区回读。W25Q 系列的扇区擦除时间标称是 400ms（整片擦除典型 4~8s），所以参数写入的整个过程耗时在 400ms 以上，这在设备运行中是不能接受的。我的做法是把参数写入放到“停机维护模式”下执行：设备只在上下电、参数下发完成后的空闲窗口更新参数区，运行时不做任何 NOR Flash 写操作。

3.4 FPGA 写 SD 卡的关键时序

FPGA 侧写 SD 卡的状态机我简化为这几个状态：IDLE → WAIT_CMD → READ_CMD → SEND_DATA → GET_RESPONSE → CHECK_BUSY → UPDATE_FAT → DONE。

其中最难调的是 CHECK_BUSY 状态。SD 卡在内部编程/擦除期间，会把 D0/Data 线拉低，表示 busy。FPGA 要在发送 CMD24（WRITE_BLOCK）之后等待 Data0 线变高再继续。具体的等待超时我设置为 500ms，超过就进入错误处理状态，记录错误计数并重新发送 CMD13 查询状态。

在数据流方面，FPGA 内部用双缓冲 BRAM：一个缓冲区在写 SD 卡，另一个缓冲区在收采样数据。缓冲区大小我设为 512 字节（正好一个扇区），这样每一次 SD 卡写操作都是整块写，不产生半扇区尾部碎片。实测下来，25MHz SDIO 时钟下连续写速度大概能到 1MB/s 左右，对采样率 100kSPS、每个采样点 4 字节的场景完全够用。

3.5 日志轮转与 SD 卡满容处理

SD 卡写满是个无法回避的问题。我的方案是“分层轮转”：FPGA 循环写固定个数的文件（比如 8 个文件，每个 64MB），写完就覆盖最旧的文件。命名规则是REC_000.DAT、REC_001.DAT……依次循环。这样 SD 卡永远有 512MB 的最新数据，不会出现“文件系统满了导致录不了数据”的情况。

STM32 侧再做一次归档：每次设备空闲时，把 NOR Flash 里的报警记录合并进 SD 卡的ALARM_YYYYMM.TXT文本文件，方便上位机直接读取。因为 FPGA 在写原始采样文件时完全不管文件系统全局状态，所以这种“两个写者”并存的情况下，必须保证它们写的是不同的文件。FPGA 只写REC_xxx.DAT，STM32 只写ALARM_xxx.TXT，接口上互不冲突。

4. 常见问题与排查技巧实录

4.1 EEPROM 写入后读回全 FF

这个问题我遇到过两次。一次是芯片本身虚焊，一次是驱动里没做写周期等待。如果读回的全是 0xFF，说明数据根本没写进去。排查步骤：先量 I2C 波形，确认 SCL/SDA 上确实有信号翻转；再用示波器抓写周期结束后的 ACK，如果 ACK 一直没等到，芯片可能处于忙状态；最后检查是不是 I2C 地址错位——AT24C256 的地址是 0xA0（8-bit 写地址），不是 0x50（7-bit 地址）。

4.2 NOR Flash 偶尔读错一个字节

这不是硬件坏了，大概率是 SPI 时序问题。W25Q64 的 SPI 模式是 Mode 0 和 Mode 3 都支持，但 STM32 的 SPI1 默认是 Mode 0。如果多个 SPI 设备复用在同一个 SPI 总线上，且其中一个设备工作在不同极性，会导致时钟极性和相位错乱。我的处理方式是：在每次切换到 NOR Flash 前，重新配置 SPI 的 CPOL/CPHA 参数，保证只用到 Mode 0，别让其它设备把配置改掉。

4.3 SD 卡频繁掉线

FPGA 写 SD 卡掉线，排查方向有四个：

第一，SD 卡电源纹波。SD 卡写入瞬间电流可达 100mA 以上，如果电源走线细、电容不够，VDD 跌落就会导致卡自行复位。解决方法是给 SD 卡 VDD 加 10uF + 100nF 双电容，并尽量让电源走线短粗。

第二，CLK 线上的干扰。25MHz 时钟的边缘很陡峭，如果 CLK 走线和高电流信号线并排，容易串扰。在 FPGA 内部给 SDIO CLK 加一个 22 欧姆串阻，可以有效抑制过冲。

第三，卡与卡之间的兼容性。不同品牌的 SD 卡对初始化时序的容忍度不一样，有的卡非要先走 SPI 模式初始化，再切 SDIO 模式。FPGA 初始化状态机里我做了“SPI 初始化握手 + 切换 SDIO”的双模式流程，兼容性大幅提升。

第四，热插拔。工业设备一般不支持运行时拔卡，但现场总有手欠的人。我加了卡检测引脚（CD）并做中断处理，如果检测到卡拔出，立即停止写操作并落一个“事件记录”到 NOR Flash；卡重新插入后自动重新初始化。

4.4 掉电瞬间 FPGA 写 SD 卡文件损坏

这个是最难搞的问题。设备意外掉电时，FPGA 可能正在写一个扇区数据，数据写到一半，卡上形成的扇区是坏的。文件系统层面 FAT 表如果还没更新，坏扇区对应的簇会在下次写入时被重新分配，一般不影响文件系统整体完整性。

我做的保护措施有两层：一层是给 FPGA 写 SD 卡增加“循环冗余写头”，即每一条记录在数据区开头带一个 4 字节的 CRC 和时间戳，上位机读取时能分辨出哪个记录是“半截”的，丢弃即可；另一层是硬件上在电源输入端加掉电检测电路，当 5V 主电源跌落到 4.7V 时，立刻拉低 FPGA 的一个紧急停止信号，FPGA 在下一个 1ms 内完成当前扇区写入并停止 SD 卡操作。这一层检测电路大概花费 0.5 元，但把文件损坏概率降到几乎为零。

5. 掉电保护与数据一致性设计

5.1 EEPROM 写序保护

EEPROM 单字节写入的原子性比 Flash 好，掉电只会导致当前字节没写完，不会影响其它字节。但为了保险，我的做法是每个参数存储两份：一份当前值，一份上次有效值。写的时候先写“当前值”，等写完再更新“上次有效值”。读取时先读“上次有效值”，如果格式校验失败，再回退到“当前值”。这样即使掉电发生在两个字节之间，系统也总能恢复到最近一次完整写入的状态。

5.2 NOR Flash 的幻数（Magic Number）机制

NOR Flash 每次参数区写入前，我会在扇区头部写一个 16 字节的 Magic Number（比如0xAA55 0x5AA5 0x1234 0x5678），表征这个扇区是否“已完整写入”。如果读取时发现 Magic Number 不匹配，就认为这个扇区数据无效，直接改用备份区。Magic Number 本身是固定的，掉电只会导致它没写全，而不会导致它“错误地看似有效”，这正是选择固定幻数而不是随机数的原因。

5.3 SD 卡掉电后 FATFS 的一致性检查

即使 FPGA 不做复杂文件操作，掉电还是可能破坏 FAT 表。我的对策是：STM32 每次开机挂载 SD 卡前，先运行 FATFS 提供的一致性检查例程（f_mount之后读取 FAT 表，检查是否有交叉链接、簇计数错误），发现问题直接格式化并重新初始化。数据文件可以丢一部分，但设备不能因为一张坏卡就起不来。

实际测试中，这套方案的掉电恢复时间大约 2 秒：EEPROM 2ms、NOR Flash 读取 3ms、SD 卡挂载最慢约 1.5 秒（因为要先做一致性检查）。在自动化产线上，2 秒恢复完全可接受。

6. 常见问题速查表

7. 关于这套方案的一些心得

最后聊点“程序之外”的东西。很多人觉得存储方案嘛，就是找来驱动、调通读写就完事，但在工业控制器这种环境下，存储方案的可靠性考核根本不是“能不能读写”，而是“掉电 1000 次之后数据还在不在”“连续写入一年之后 Flash 还经不经受得住”“换了 20 张不同牌子 SD 卡之后有没有一张卡出幺蛾子”。所以我认为，至少在工业控制器领域，存储设计的重心 70% 要放在掉电处理、校验、降级策略上，只有 30% 是读写驱动本身。

还有个小建议：如果你正在设计类似的存储分级，优先把 EEPROM 这一级做扎实。因为参数数据的可靠性直接决定设备能不能正常启动、校准能不能通过。NOR Flash 和 SD 卡的数据丢失，最多损失“记录”和“日志”，但参数丢了设备就瘫了。所以 EEPROM 这一级我花了最多的时间做回读校验和双区冗余，事实证明这笔投入是完全值得的。

这套 STM32+FPGA 分级存储方案从硬件定型到量产大约用了两个月，其中 FPGA 侧 SD 卡状态机用了两周，STM32 侧 EEPROM/NOR Flash 驱动用了三天，剩下的时间全部耗在各种边界条件测试上：掉电、毛刺、弱卡、长文件名、文件系统碎片化。如果你也要做类似的东西，建议从一开始就把“异常测试”列进计划，不要等活动板跑通了再补，不然后面改结构会非常痛苦。