做工业控制器最容易翻车的地方往往是存储。很多项目一开始图省事把配置参数、日志、算法系数全塞进 STM32 内部 Flash现场跑一段时间就发现问题改一次参数要擦掉整个扇区日志还没记几天就担心把程序区也拖下水FPGA 那边采回来的高速数据更是没地方倒。后来我把整套数据拆成 EEPROM、NOR Flash、SD 卡三级STM32 负责按数据的“脾气”分派存储介质FPGA 负责把高速采集的数据平稳交给 CPU这才算把存储这口锅彻底端稳了。这篇文章就把这套分级存储方案的关键设计和盘托出适合正在做工业控制器、运动控制板、边缘网关或者 STM32FPGA 双芯方案的工程师参考。1. 存储分级为什么是工业控制器的刚需1.1 三种存储介质的本质差异先别急着写代码得先把三类介质的“性格”摸清楚。EEPROM 像便利贴可以随时擦掉改写一小块按字节操作擦写寿命通常在 100 万次级别但容量很小几百千字节就算顶天了。NOR Flash 像打印好的手册读取可以按字节或按页高速访问甚至支持 XIP片上执行但写入必须先擦除整个扇区寿命一般是 10 万次左右容量能从几兆字节做到几百兆字节。SD 卡则是移动硬盘容量以 GB 计适合大量数据堆放但写寿命、实时性和可预测性都受文件系统和卡本身的 FTL 管理限制。这三者不是替代关系而是互补关系。工程上最常见的错误是希望一颗芯片干完所有事小容量记不下日志大容量又舍不得频繁擦写最后两边都受害。分级存储的本质是让每一类数据落在“它最擅长”的介质上。数据类别典型内容单个大小写频率可靠性要求推荐介质关键配置PID 参数、设备地址、校准系数几十字节低仅更改时写掉电不能丢不能损坏EEPROM运行状态小变量当前批次号、故障累计次数几字节中定时/掉电写尽量不丢EEPROM启动代码/位流应用程序镜像、FPGA bitstream几百千字节到几兆极低升级时写完整性要求极高NOR Flash运行日志/历史数据报警记录、采样波形、温湿度曲线连续追加高每秒甚至毫秒级允许丢失最近几秒数据SD 卡临时高速缓存FPGA 采样帧、网络上传缓冲几兆到几十兆极高允许重启后丢失DDR/SDRAM注意表格里我特意把“掉电不能丢”和“允许丢几秒”分开。工业现场判断存储方案好不好第一个标准不是容量多大而是掉电那一瞬间数据是否还在预期位置。1.2 分级原则按数据生命周期和可靠性需求分配分级不是拍脑袋而是按两个维度去分数据生命周期以及数据对完整性的敏感度。数据生命周期看的是“多久变一次”。PID 参数可能几天甚至几个月才调一次传感器零点校准值只有开机标定时才更新这些属于低频写入。报警日志可能每分钟都在产生波形采样数据更是毫秒级刷新这些属于高频写入。让高频数据去写 EEPROM就是把便利贴当草稿本用寿命撑不过现场运行几个月。反过来把低频但至关重要的参数丢来 SD 卡万一卡上文件系统损坏设备可能连启动配置都没了这是不可接受的。可靠性敏感度更关键。启动代码如果读出来错 1 bit整个系统可能就起不来所以对 NOR Flash 里的镜像要做 CRC 校验。设备地址、MAC 地址这类参数如果写坏一位设备会从网络上“消失”所以更适合放 EEPROM再加上双备份和校验字。日志类数据的要求是“尽量多、尽量全”偶尔丢几个字节反而可以接受SD 卡的适用场景就在这里。1.3 STM32 和 FPGA 在这个方案里各自扮演什么角色很多朋友对 STM32FPGA 的分工理解成“STM32 管存储FPGA 管逻辑”这没错但太粗了。实际项目里FPGA 往往是数据生产者而且生产速度远高于 STM32 能直接消费的速度。例如 FPGA 做多通道 ADC 同步采样单通道 1 kHz、16 bit多通道一秒就是几十千字节如果做图像采集或者振动分析数据率能到几兆字节每秒。STM32 去轮询读这些数据再逐个写卡主频再高也扛不住。所以我的做法是FPGA 先把数据收进片内 FIFO 或片外 DDR然后通过并行总线、SPI 或 UART 以批量突发方式交给 STM32STM32 利用 DMA 接收后再按前面表格的规则分别写入不同介质。STM32 是整个存储系统的“调度中心”FPGA 是“数据中继站”两边各管一头再用帧协议把中间链路兜住。这种架构最大的好处是解耦FPGA 不需要关心数据最终落在哪个介质上只需要保证“我发出去的数据不丢、有序”STM32 不需要关心采样时序和高速缓存只需要从队列里取数据做分级落盘。哪一侧出了问题都能单独定位、单独测试。2. 硬件电路与接口选型细节2.1 EEPROM 选型与接线EEPROM 最常见的是 AT24C 系列从 AT24C01 到 AT24C256I2C 接口容量从 1Kbit 到 256Kbit。工业控制器里我一般选 AT24C64 或者 AT24C12864KB 的配置空间足够放几十组配方了。选型时注意几点芯片的 A0/A1/A2 地址引脚实际 I2C 设备地址是 0xA0 | (A22) | (A11) | A0如果板上只放一颗把三个引脚统一接地即可。SCL/SDA 上拉电阻典型 4.7kΩ总线速度快或者节点多的时候减小到 2.2kΩ。上拉电阻太大会导致上升沿过缓I2C 波形识别失败太小会增大功耗注意别超过芯片规格。WP 写保护引脚要接地或者拉到 IO 口控制。我踩过一次坑原理图上 WP 悬空结果写入操作偶发失败查了半天才发现是引脚浮空导致写保护状态不稳定。STM32 的 I2C 外设老库在部分芯片上有“死锁”毛病如果你用的芯片型号比较老图省事可以直接用软件模拟 I2C代码量不大但可靠得多。新的 Cube HAL 硬件 I2C 通常没问题但还是要做超时和复位处理。电源上EEPROM 对噪声不算敏感但建议在 VCC 和 GND 之间放一个 100nF 陶瓷电容尽量靠近芯片引脚。工业环境下如果总线长度超过十几厘米SCL/SDA 上还可以各串一个 100Ω 电阻降低振铃。2.2 NOR Flash 选型与接线NOR Flash 我用得最多的是 W25Q 系列比如 W25Q32、W25Q64、W25Q128SPI/QSPI 接口。它们容量 4MB 到 16MB页编程一般 256B扇区擦除 4KB块擦除 64KB支持最大 80MHz 左右的 SPI 时钟。工业控制器里放 FPGA bitstream、字库、启动镜像16MB 绰绰有余。接线有几个细节容易出问题。一个是 /WP 和 /HOLD 引脚数据手册经常写“内部默认上拉”但在实际布板上很多芯片引脚的内部上拉并不稳定强烈建议外部接 10kΩ 上拉到 VCC。否则 /HOLD 被拉低时 Flash 会暂停所有操作写一半停在半空你查代码真查不出原因。另一个是片选引脚 /CS必须由主控明确控制而且在整个写入序列期间保持低电平不能中途拉高去响应别的中断延时这也是测试环境里最容易忽略的问题。SPI 引脚分配上建议把 CS 用普通 GPIO 控制而不是硬件外设自动控制这样时序更可控排查问题时直接读 GPIO 电平就能确认。SCK、MOSI、MISO 优先用硬件 SPI 的片选引脚映射但 CS 手动控制反而更稳。驱动能力上如果 SCK 频率超过 20MHz最好在主控端串 10~22Ω 电阻走线长度别超过 5cm否则高速振铃会让 Flash 读回随机 bit 反转。2.3 SD 卡接口设计SD 卡有 SDIO 和 SPI 两种最常见模式。STM32 如果资源允许优先选 SDIO 4-bit 模式速度快适合日志流量大的场景如果引脚吃紧SPI 模式也可以用但速度要打折通常能到 10~20 Mbps 就很好了。很多小批量产品里我用 SPI 模式省引脚日志吞吐量足够代码还简单。卡座选择上我习惯用带卡检测引脚的自弹式 microSD 卡座CD 脚连一个 GPIO 做热插拔检测。注意给卡座预留足够的机械空间和接地支撑震动环境里卡座焊盘容易裂。供电是重灾区。SD 卡的闪存颗粒在写入时会有电流尖峰如果 3.3V 电源没有足够储能电容尖峰一拉低电压卡就复位也就是现场常见的“写日志写到一半卡没了”。我一般在 SD 卡座 VCC 附近放一个 100μF 钽电容加 100nF 陶瓷电容的组合钽电容 ESR 低扛瞬态能力好再远一点在板级 3.3V 母线处加 100μF 电解。信号线上按高速数字规则处理能短则短MISO/MOSI/CLK 可以串 22Ω 电阻。如果系统里同时接了 NOR Flash 和 SD 卡建议把两者的时钟源分开考虑避免 SPI 高速时钟辐射干扰 SD 卡线。有些板子为了走线好看把 W25Q 和 SD 卡共用一组 SPI只靠 CS 区分从功能上没问题但从时序和调试复杂度上讲不如各自独立总线来得干净。2.4 加入 FPGA 后的总线架构STM32 和 FPGA 之间怎么连直接决定这套存储方案能不能跑得动。按数据吞吐量我把它分成三类低速物理量比如几个串口数据、开关量、温度采样吞吐在每秒几 KB 以内STM32 和 FPGA 之间用普通 UART 或 SPI 即可FPGA 侧只需要简单的 FIFO。中速数据比如多通道 ADC 同步采样吞吐几十到几百 KB/sSPI 加 DMA 能解决FPGA 侧数据要打成帧帧头加 CRCSTM32 收完一帧再批处理。高速数据比如图像、整帧振动波形、光纤通信吞吐几 MB/s 以上这时候不能让 FPGA 往 STM32 内部 SRAM 里塞了必须用 DDR 做中转FPGA 写 DDRSTM32 通过 DMA 从 DDR 读出来再落盘。这个场景通常还要配合“多端口 DDR”设计后续我会单独写一篇这里先不展开。无论哪种核心原则都一句话FPGA 不直接操作存储介质STM32 是唯一存储主控。为什么因为文件系统、掉电时序、磨损均衡这些逻辑在 CPU 上做太成熟了比如 FatFS 写 SD 卡重试和缓存管理都很完善非要在 FPGA 里实现 FatFS不仅代码量爆炸出问题之后调试手段也非常有限。维持这条分工线FPGA 侧只专心做数据搬运和协议解包STM32 侧专心做媒体管理两侧都清爽。3. 软件与 FPGA 逻辑的核心实现3.1 STM32 侧驱动设计EEPROM 驱动要重点理解“页写边界”。AT24C 系列一页通常是 8 字节或 32 字节I2C 连续写数据如果跨页写入会被截断。高字节地址翻转之后实际上又写回页内偏移 0数据全乱。所以写 EEPROM 的标准做法是先计算当前页剩余空间超过一页就拆分多次写。比如写 64 字节配置一页 32B就拆成 32B32B每次写完等待 5ms 写周期或者用 ACK 轮询方式判断。NOR Flash 驱动比 EEPROM 复杂一个维度核心是“写前必须擦”。NOR Flash 存储单元只能从 1 变成 0所以要让任意字节变成 0xFF 再写入新值必须先把扇区擦除。也就是说你只想改某扇区里的 4 字节也得先把整个扇区读到内存修改再擦除整扇区然后写回。代码逻辑上分四步发送 Write Enable (0x06)并对返回状态确认 WEL 位已置位。发 Page Program (0x02)一次最多写 256B地址不能跨页跨页要拆。轮询状态寄存器 (0x05)等 BUSY 位清零。读回校验避免总线时序问题导致静默写错。擦除也分扇区擦除 (0x20)、块擦除 (0xD8)、整片擦除 (0xC7)。整片擦除别在产品代码里轻易调用万一手滑配置全没了。擦除耗时较长我的建议是把它放到后台任务里或者进掉电保存流程之前单独处理不要在定时中断里做。SD 卡这边用 FatFS 会省很多事。但要注意 f_write 之后数据不一定真正落到了物理扇区文件系统只是把数据写进了 FatFS 的缓冲区和卡的内部 DRAM得 f_sync 之后才保证落盘。周期性调用 f_sync 是保命操作后面排查章节我会详细说。还有一点写日志文件时尽量用追加模式打开不要每写一行就打开关闭一次否则卡上的 FAT 表会被反复更新目录项碎裂文件操作越跑越慢。3.2 FPGA 侧数据通路FPGA 侧的数据通路设计核心是 FIFO 和双缓冲。先说 FIFO。ADC 采样时钟和 STM32 SPI 读时钟肯定不是同一个时钟域必须有异步 FIFO 做跨时钟域缓冲。FIFO 深度要按“最恶劣突发”估算假设采样 8 通道、每通道 16bit、1 kHz即 16KB/sSPI 时钟 8MHz差不多 1MB/s 读取能力看起来富裕。但假如 STM32 正在写 SD 卡写卡导致 SPI 读请求被暂停 100ms这 100ms 里 FIFO 至少要吸收 1.6KB 数据所以深度不能小于 2KB我实际给到 4KB留出裕量。深度取 2 的幂反正 FPGA 内部 BRAM 按块分配。双缓冲比单一 FIFO 更适合“批量搬运”场景。FPGA 侧每采满 1KB 数据就在 A、B 两块缓冲之间切换A 填满后立即使能 STM32 的 DMA 读取同时 FPGA 往 B 里继续填STM32 读完 A 后切换到读 B形成乒乓。这样带宽利用率更高也不会因为 FPGA 写 FIFO 和 CPU 读 FIFO 的竞争导致卡顿。帧协议上我通用格式是2B 帧头 (0xAA55)、1B 通道号、2B 数据长度、长度字节数据、4B CRC32。STM32 收到帧先查帧头长度超限则丢帧CRC 不对则请求重发。如果您做的是 UDP 或 TCP 上行转发这个帧格式还可以原样向上透传省一套打包逻辑。3.3 “分级”落库策略驱动写好了数据通路也通了接下来就是落库策略。这一部分最有工程味道因为要回答“什么数据写哪里、多久写一次”。我习惯先建一张数据映射表每类数据占多少字节、多久产生一级、掉电能不能丢、允许的最大写入延迟。拿一个典型的控制器举例数据项大小产生频率掉电策略存储介质落盘触发PID 参数组128B修改时一次必须保存EEPROM收到写配置命令后立即写零点校准值8B/通道开机标定必须保存EEPROM标定完成后立即写配方表2KB修改时一次必须保存NOR Flash收到配方上传命令后视频擦写FPGA bitstream600KB升级时一次必须保存且完整NOR Flash升级工具整包写入 CRC 回读运行日志128B/秒1Hz允许丢 30 秒SD 卡每 30 秒 f_sync 一次事件记录64B/条随机尽可能保存SD 卡事件触发后 200ms 内写入并 sync这张表有两点我很强调一是 EEPROM 里只放“改了就立刻要保命”的数据像累计运行时间这种一分钟更新一次就不该放 EEPROM直接落 SD 卡日志反正掉了也无所谓二是 SD 卡日志允许丢 30 秒这是设计出来的容忍度有了容忍度f_sync 频率就可以降到 1/30s卡磨损和 CPU 负担都小很多。工程上最怕的是一拍脑袋“每个数据都要实时落盘”最后哪一块都没落好。3.4 掉电保护与一致性设计掉电保护是工业控制器存储方案的生死线。你不能假设现场停电总是“温柔”的更多时候是断路器直接跳闸、整柜瞬间断电。这时候所有存储系统都必须在“最后几毫秒”里处理好该处理的数据。硬件侧我强烈建议加一个外部掉电检测复位芯片比单纯用 STM32 内部 BOR 更可靠。典型接法电源监控芯片检测 3.3V 降到阈值以下时立刻向 STM32 的 EXTI 脚输出中断同时把 NOR Flash 和 SD 卡置于写保护或低功耗模式。STM32 收到中断后从正常工作流切到一个极简保存上下文函数里只把最关键的几十字节 EEPROM 数据写完其他一律不管。这里的关键是 EEPROM 写一个页只需 5ms 左右掉电保持时间通常有 20ms 以上足够完成。NOR Flash 就不适合在这种场景下紧急写因为擦除太慢大概率写一半掉电反倒把好数据都破坏了。数据一致性上所有介质上的数据都要带“头数据校验”的结构。我在 EEPROM 和 NOR Flash 中都固定放一个 16 字节的头部4B Magic、2B 版本号、4B 数据长度、4B CRC32、2B 预留。上电时先读头部Magic 不对、CRC 不对、长度异常就把备份区的数据搬回来。备份区可以简单理解成“同一数据写两份”一份主区一份备份区写入顺序先备份后主区这样即使写到一半掉电主区还留着旧版本等下次上电校验过不了就会自动回滚。SD 卡的一致性主要靠 Flush 策略。日志数据不要实时写而是攒到一定量再写默认定时 30 秒 f_sync 一次正常关机时先 unmount确保 FAT 表落盘完整。针对突发断电我还会在日志文件里每行加序列号和 CRC开机后扫描最后一个有效序列号从此处恢复追加这样即使文件系统元数据有轻微损坏也能通过应用层协议把日志内容尽可能救回来。4. 实操中踩过的坑与排查方法4.1 I2C 死锁和 EEPROM 写入不稳定的排查EEPROM 项目里最经典的问题是 I2C 总线死锁现象是 SDA 被拉低SCL 还在正常跳STM32 的 I2C 外设状态寄存器停在忙状态所有读写全部卡住。根因通常是主机时序在传输中途被打断比如写 EEPROM 时来了一个更高优先级的中断导致 SCL 停止翻转此时 EEPROM 在等待 9 个时钟完成内部状态机复位恰好 SDA 又处于从机输出位于是总线被堵死。解决思路是加一个 I2C 总线恢复函数当检测到 SDA 一直为低或外设超时就强制拉 SCL 产生 9 个时钟脉冲让从机释放 SDA然后再重新初始化 I2C。这个函数要在每次传输失败后调用并且设置足够短的超时时间。写入不稳定的另一个常见原因是地址页跨越。AT24C64 一页是 32B如果写 64B 配置没做拆分第二页实际上写不进读出来全是 0xFF。排查时先读回刚写入的区域看看是不是前 32B 正常、后 32B 全 FF基本一抓一个准。另外上拉电阻质量差也会偶发写入失败如果你用逻辑分析仪抓到 SCL/SDA 上升沿有明显爬坡把上拉电阻从 10kΩ 换到 4.7kΩ 或 2.2kΩ 往往能直接解决。4.2 NOR Flash 擦写错位、数据反转的根因分析NOR Flash 最常见的故障是“写进去的东西变了样”在线下测试环境里表现为写入 0x55读出来是 0xAA或者写 128B读回时后面的数据出现在前面。第一个根因是跨页编程。和 EEPROM 的道理一样W25Q 的页是 256B页编程命令不能跨页。假如你要写 300B地址从页内偏移 200 开始一次发 300BFlash 会从页边界处“回卷”把后面 44B 写到页开头直接覆盖掉前面的内容。排查方法很简单把所有写操作统一封装成“拆分到页边界”的函数再写长度任意测试数据回读校验就能暴露。第二个根因是硬件引脚干扰。/HOLD 和 /WP 引脚如果悬空或走线过长在高速 SPI 时钟下体会被串扰拉低导致 Flash 暂停或进入写保护。我遇到过一板子量产时偶发数据反转最后用示波器抓 /HOLD发现波形上有毛刺跌到低电平重新布局并接上拉后彻底解决。排查这类问题最好的办法是一边用逻辑分析仪抓 SPI 四根线、一边反复读写固定 pattern同时观察 /CS 高低电平和 /HOLD 状态。第三个根因是擦除和写入没有充分等待 BUSY。W25Q 页编程一般在几十微秒到几毫秒扇区擦除要几百毫秒。如果你发完 0x02 觉得“应该写完了”立刻去读数据很可能读到 0xFF因为芯片内部还没忙完。所有写和擦操作后必须轮询读状态寄存器的 BUSY 位直到它清零。4.3 SD 卡日志丢失、文件系统损坏的处理SD 卡日志我踩过最大的坑是设备在雷雨天气里频繁断电一个月后拔卡回来读文件发现目录能打开但日志文件的大小只有预期的三分之一中间还夹杂着 FF 填充的乱码区域。原因就是频繁断电时FatFS 只是把内容写进了文件系统的缓存和卡的内部缓存没有及时 f_sync暴露电瞬间 FAT 表没有完整写卡导致文件簇链断裂。格式还能认到但有效数据丢了。解决办法已经在落库策略里讲过了周期性 f_sync日志文件固定大小不加不加新的目录项同时应用层协议加序列号和 CRC。上电后做一个“日志恢复”流程扫描最后有效记录把损坏的尾部直接截断不再追加到坏数据后面。另一个容易被低估的问题是 SD 卡的供电。卡在写操作时的瞬态电流可以达到 100mA 以上如果电源压降超过 200mV卡内部逻辑就可能复位。表现很迷惑写日志卡初始化正常但一执行 f_write 就返回错误连格式化和读卡都正常。用示波器看卡 VCC如果能观察到写入瞬间电压跌到 3.0V 以下那就是电容不够把 100μF 钽电容加上去基本就完事。4.4 STM32 与 FPGA 联调时常见通信问题STM32 读 FPGA 数据时最典型的现象是“第一个字节丢、后面全乱套”十次里有八次是 SPI 模式没对上。FPGA 如果按 Mode 0 发数据STM32 配成 Mode 3边沿差一个相位第一个字节往往会被吞掉。排查时我先用固定帧 0x55AA55AA 去灌让 FPGA 循环发送STM32 只捕获并打印立刻就能看出是极性还是相位问题。第二个高频问题是 MISO 三态控制。FPGA 的 MISO 引脚必须在 CS 拉低时才驱动总线CS 拉高时必须置高阻否则多个 SPI 设备在 MISO 线上打架读出来的数据会被拉到不定电平。检查 FPGA 代码里 MISO 的赋值条件是否只依赖 CS是这一问题的标准切入点。第三个问题是 FIFO 溢出。STM32 接收速度低于 FPGA 产生速度时FIFO 满了之后新的采样帧只能被丢弃。我的处理方式是 FPGA 在 FIFO 满时把状态寄存器的一个标志位置位STM32 每个周期来读这个标志如果发现溢出就重启 SPI DMA并从最后一包完整数据继续。这样虽然丢了几个采样周期但不会导致整段数据协议错位比“被动等CPU来读”稳健得多。4.5 实测经验小结我做这套方案时有一组数据可以用数字直观说明为什么这么设计不会亏EEPROM 存 64B 关键配置按每天写 100 次算100 万次寿命可以撑约 27 年整个设备寿命周期内根本不用考虑磨损耗尽。NOR Flash 存 FPGA bitstream平时只有升级才写一次寿命压力完全不在擦写上读取走了 XIP 或者内存映射速度足够。SD 卡按 1KB/s 写日志一张 32GB 卡理论上能写约 1.3 年现场用循环覆盖策略后实际卡的寿命瓶颈反而是磨损失效不是容量。所以存储分级的价值不在于选多高级的硬件而在于把有限资源用在最需要的地方让每类介质都工作在它擅长的频率和容量区间里。这个思路和选芯片、调 SPI 时序同等重要但容易被经验不足的工程师忽略。我个人在实际操作中的体会是设计这套方案最值得投入精力的不是写驱动而是画“数据映射表”和“掉电时序图”。你在板子还没焊好、FPGA 代码还没编译之前先把哪类数据落到哪个介质、写入频率是多少、掉电时允许丢多少都列清楚后面做驱动和调试会少走一大半弯路。最后分享一个救过我几次现场的小技巧给 EEPROM 和 NOR Flash 的数据块统一加一个 magic 字加 CRC 的版本头上电后先校验主区不匹配就自动从备份区恢复。这功能只有几行代码却是整个存储系统最后一道安全网。