做硬件的都知道工业控制器里存储这件事远没有想象中那么“插个芯片就能存”。尤其当系统里同时有STM32和FPGA两个处理器各有各的数据要落盘各有各的时序要求存储方案一旦拍脑袋定后面就是改不完的板子、写不完的补丁。这篇就按我实际做过的一个工业控制器项目把STM32FPGA的分级存储方案掰开揉碎讲一遍涉及EEPROM、NOR Flash、SD卡三种介质各自管哪摊活以及硬件上、软件上那些容易踩的坑。1. 为什么工业控制器需要“分级”存储1.1 一个被低估的问题数据量一上来方案全乱套刚接手这个项目的时候需求表上写得轻飘飘一句话“支持参数保存、历史数据记录、掉电不丢失。”等真正梳理完数据流才发现这九个字背后藏着三类完全不同的存储需求第一类是配置参数比如通信波特率、PID调节系数、校准值、设备序列号。特点是数据量极小最多几KB但要求随时可改、掉电不能丢、改错了要能回退。第二类是过程数据比如温度曲线采样、伺服位置历史、报警事件记录。特点是数据量中等每天可能产生几MB到几十MB需要一段时间内可追溯但不要求永久保存覆盖掉老数据也无所谓。第三类是大块文件比如设备升级固件、配方文件、故障前后的波形录像。特点是体积大、偶发写入、读取频率不高但一旦要读就必须完整可靠。如果这三种需求全塞进同一个Flash芯片里后果是灾难性的参数频繁改写会很快把Flash寿命耗尽历史数据擦写又会影响参数碎片的读写效率大文件占用的块还会把环形覆盖区域堵死。分级存储的核心思路就是不让不同时序、不同生命周期、不同容量要求的数据互相干扰把合适的介质放在合适的层级。1.2 四级存储各管哪一摊看得见的大路货看不见的门道我把这个控制器最终分成了四层分别是MCU内部Flash、外部EEPROM、NOR Flash、SD卡。很多人会问MCU内部Flash不是也能存吗对能存但只敢用来存Bootloader和APP固件顶多存几个需要原子性更新的小标志。内部Flash的擦除粒度太大寿命也不够折腾频繁写参数会把程序区磨坏这是工业现场最不想看到的事。外部EEPROM典型型号AT24C128、AT24C256承担第一级存储所有需要频繁修改、字节级操作的配置参数。选它而不是用NOR Flash核心原因是EEPROM按字节擦写寿命高硬件ECC误码率低写入速度对紧凑参数而言完全够用。第二级是NOR Flash我用的是华邦W25Q648MB。它的活是存历史过程数据和环形日志。按扇区擦除、顺序写入的方式做成一个“环形仓库”写满了从最老的数据开始覆盖。NOR Flash的随机读取性能和可靠性在这层很关键因为历史数据不是只写不读上位机随时可能来拉一段曲线要能快速定位、连续出数。第三级才是SD卡存固件升级包、配方备份、故障录像这类大文件。SD卡的容量优势无可替代8GB起步配合FatFS文件系统可以直接在电脑上读出来调试维护都方便。但SD卡在工业环境有天然弱点——接触可靠性和掉电一致性所以只让它承担不频繁但体积大的写入绝不让它当“主力存储”。1.3 选型原则不要只看容量要算“寿命账”和“时延账”选存储介质我是先算寿命再算时延最后才看容量。工业控制器设计要求至少运行10年一年365天每天存储系统都在工作。以参数区为例假设每秒写一次配置其实实际没这么频繁EEPROM的AT24C128擦写寿命是100万次10年约3.15亿次写入压力远远不够。但实际工程中配置参数只在上电或调试时写入真正高频写入的只有运行状态记录那个放NOR Flash环形区。NOR Flash的10万次擦除寿命看起来也不高但如果按每天覆盖一个2MB分区来算10万次能用约270年完全能覆盖设备生命周期。时延方面EEPROM页写以字节为单位写入一个参数通常5ms内完成适合掉电瞬间抢存。NOR Flash写一个页256字节需要0.7ms左右但擦除一个扇区需要150ms所以绝不能把高频改写的数据放在NOR Flash。SD卡就更不用说了一次写入还要兼顾文件系统开销毫秒级到几十毫秒不等掉电瞬间根本抢不完。一句话总结选型账“小参数找EEPROM中速历史找NOR Flash大文件找SD卡MCU内部Flash只放程序。”这四句话就是我整个存储方案的架构基础。2. 核心选型与原理EEPROM、NOR Flash、SD卡各自的分工2.1 EEPROM的本质能按字节改的“小账本”EEPROM早期的名字叫“电可擦除可编程只读存储器”听名字很绕用人话讲就是一个能按字节单独擦写的电阻网络。它内部每一个存储单元其实是一个浮栅晶体管通过控制栅极充电来存“0”或“1”。因为工艺上的对称性设计它支持单字节擦写而NOR Flash只能按扇区擦除这就是两者本质区别。项目里我用的是AT24C128I2C接口16KB容量分256个page每page 64字节。I2C总线上挂它和温度传感器、RTC地址用A0/A1/A2三个引脚区分。在STM32的HAL库下读写就是HAL_I2C_Mem_Write()和HAL_I2C_Mem_Read()但硬件上要注意WP引脚必须拉到GND否则写保护开启后所有写操作都会被硬件丢弃导致参数永远保存不上排查这种问题特别费时间。EEPROM写入有自己的脾气页写操作有个“跨页陷阱”。AT24C128的页写虽然支持一次连写64字节但如果写入跨越了页边界数据会回卷到当前页开头把原来的数据覆盖掉。实际工程中我处理的参数表是结构体打包的很容易超过64字节的页边界所以必须按页切分写入或者用I2C硬件控制、逐条写入。这个问题不提前处理现场改参数改乱就是必然的。2.2 NOR Flash为什么能承担“大历史”而不怕更久NOR Flash被选来当历史数据仓库是因为它在读取随机性和擦除寿命之间做到了比较好的平衡。W25Q64内部的存储阵列按扇区组织一个扇区4KB擦除以扇区为单位写入以页256字节为单位。这个特性决定了它适合顺序日志型写入数据不断追加写满一个扇区再擦下一个。如果做随机改写字节能把人逼疯——先读整扇区到RAM改字节再整扇区擦除重写效率极低寿命折损也大。我把它设计成环形缓冲区划分出N个扇区作为数据区起始位置记录在头部保留的“日志指针扇区”。当数据写满当前扇区先把指针扇区里的偏移改掉再擦除下一个扇区。这样任何时刻逻辑上都是“顺序写、环形覆盖”磨损被均匀分摊到每个扇区有效寿命比固定位置写入高出一个数量级。另外NOR Flash在工业现场还有个大优点——XIP片上执行Execute in Place。有些对时间敏感的诊断程序可以从Flash直接跑不用拷贝到RAM。FPGA侧的校正系数表也可以直接放在NOR Flash映射区上电后FPGA自己读不用惊动STM32。这个特性让NOR Flash在系统里承担了“半个内存”的角色供电稳定后读数据几乎是零时延。2.3 SD卡是大仓库但仓库管理员是FatFSSD卡的优势不用多说要大容量、要方便电脑读取它有天然优势。协议上SPI模式实现简单STM32的SDIO接口还能达到更高吞吐项目里我用SDIODMA方式写大文件时的实际速率在8MB/s左右够用。SD卡管理我直接上了FatFS开一个小分区目录结构按日期分文件夹/RECORD/2024/0801/下面就是当天的数据文件。这样在PC上翻查资料非常直观。FatFS的参数配置有几个关键点。一是_FS_MINIMIZE得设为2权限管控不要开太多否则RAM占用太大。二是**_VOLUMES要设成1**这个板子只有一张卡别让文件系统去枚举多余卷。三是_USE_LFN长文件名编译选项要打开否则8.3短文件名在日期目录里非常难认。系统掉电前必须调用f_sync()把文件缓冲刷到SD卡掉电瞬间丢缓存是FatFS老生常谈的坑。SD卡这一层还有个额外的保险我留了一个版本号头文件在文件系统里每次固件升级时Bootloader先从SD卡读校验再决定是否进入升级流程。这个思路把升级包和运行数据物理隔离出问题时数据还在卡里不会因为升级失败被连带清掉。3. 硬件设计要点布局、电路与上电时序3.1 总线拓扑与上拉电阻I2C那点事儿EEPROM挂在I2C总线上这条总线同时挂了RTC和温度传感器总共三个从机。I2C是开漏结构所以上拉电阻非常关键。3.3V供电下我选4.7kΩ上拉。总线长度超过10cm后4.7kΩ可能扛不住分布电容会出现偶发的ACK丢失这时候降到2.2kΩ波形会干净很多。这个细节在单板调试时很难复现一上批量、线缆一长就露馅属于“看起来是软件问题其实是硬件问题”的典型。I2C地址方面AT24C128的地址是0xA0A2/A1/A0的组合当总线上有两颗EEPROM时用地址线区分。我这边板上只用一颗EEPROMA0/A1/A2全部接GND地址固定。调试时用逻辑分析仪抓I2C波形这是定位EEPROM读写问题最快的手段不要只盯寄存器。3.2 写保护与掉电保护的双保险EEPROM的WP引脚我拨到GND还串联了个0欧电阻把引脚引出到测试点。这个设计在产测时很有用产线需要烧录校准参数如果WP拉高锁定写不进去产测程序卡住半天才发现。通过0欧电阻断开WP生产时先解锁烧录出厂前再把0欧补上锁定既保证生产方便又防止现场误写。虽然这是电路板小技巧但绝对值得抄进设计规范里。电源掉电保护是整个存储方案的生命线。NOR Flash擦写中间掉电会留下部分擦除的扇区SD卡写文件时掉电可能损坏FAT表。我在板上设计了掉电检测电路一颗电压比较器监测5V输入一旦电压跌落到4.65V以下立即拉低STM32的外部中断引脚。STM32在中断里只干三件事关全局中断、把关键缓存区的数据写入EEPROM页写区、向FatFS发f_sync()。这套流程配合板上大电容1000µF做能量支撑实测能给系统争取到120ms的“黄金保存时间”足够处理参数保存和文件系统收尾。上电时序同样不能马虎。W25Q64的复位和初始化需要稳定的供电我给它加了RC延时电路保证FPGA配置完成后NOR Flash才被访问。否则上电瞬间FPGA去读FlashFlash还没就绪读回来的全是0xFF校正系数全错故障排查会非常痛苦。3.3 FPGA侧为什么仍要保存参数但优先在STM32FPGA这边也有自己的非易失存储需求比如逻辑配置本身固化在SPI Flash里、图像处理校正系数、脉冲输出标定值等。最开始我考虑让FPGA直接挂EEPROM自己读后来还是改成了FPGA只通过内部寄存器向STM32请求参数由STM32统一管理存储。原因有几个。第一是管理一致性参数表只有一个权威源FPGA要什么参数就去向STM32要不会出现“两边各存一份、版本不一致”的问题。第二是操作时序FPGA侧逻辑对I2C时序不敏感硬核实现虽然能跑但调试复杂占用的逻辑资源也不划算。第三是掉电一致性掉电时FPGA不可能自己完成“刷新取消→保存备份”这种多步操作STM32的中断处理要可靠得多。FPGA侧真正需要自己访问存储的场景很少最多就是上电后自动读取校正系数做自检。这种读操作也简单让FPGA在配置完成后拉一个“参数请求”信号STM32从EEPROM读出来回给它。这样存储介质就全部集中在STM32这一侧硬件资源好规划固件升级也只动一个地方。4. 软件实现的关键步骤4.1 STM32端的抽象一个存储管理层把所有介质统一成接口写代码之前先定数据结构我建了一个存储管理层把四种介质MCU内部Flash、EEPROM、NOR Flash、SD卡统一抽象成读写接口。对外只暴露四个函数store_param()、load_param()、cache_write()、file_write()。上层业务逻辑完全不关心数据落在哪块介质上底层映射关系放在一个配置表里。这样做的好处是后面换芯片、换介质改配置表就行业务代码一行不动。参数表用结构体定义包含设备ID、通信配置、PID系数、校准值。每个字段加CRC32校验防止存储介质返回脏数据。每次写入EEPROM时不盲目全量写只比较新旧值有变化的字段才写。工业控制器的参数属性要是没做这层diffEEPROM寿命分分钟被粗心的业务逻辑耗尽。EEPROM写流程我用了“两遍写入”策略第一遍写入再读回校验不对就再写一遍仍然不对就报存储异常同时把参数标记为“默认值”继续运行。这个做法在批量生产中很有效因为有些批次的EEPROM存在偶发位翻转问题两遍写入能把误码压到几乎为零。4.2 EEPROM写操作要防“半写”和“跨页”EEPROM写操作最怕“半写”写过程中掉电字节只剩一半数据CRC校验直接不过。我的做法是把参数表拆成两个Bank每个Bank存储一份完整数据外加一个“当前有效”标志位。写入时先写Bank B校验通过后写Bank A最后把标志位翻转到Bank A。读取时如果Bank A校验失败就自动加载Bank B同时启动一次后台自修复。这样任何时刻至少有一个完整有效的参数副本在设备里掉电、干扰都破坏不了“完整性”这个底线。跨页问题前面提过我再详细说下处理。AT24C128每页64字节参数表200多字节直接写必然跨页。处理方法是把参数表按64字节切块一页一页写页内数据不能跨页连续。实际编码上我用一个struct_eeprom_page结构体把参数表填充到以页为边界的多块缓冲每次写一页页间地址对齐。切页逻辑写完之后再用逻辑分析仪确认A9/A8地址切换无异常。4.3 NOR Flash的环形覆盖和磨损均衡NOR Flash的写入代码我封装成“日志追加器”对外提供log_append()和log_read_seq()。内部维护一个“写指针”和“读指针”写指针指向当前写入扇区读指针用于回放历史数据。每次启动时扫描头部指针扇区恢复上一次的状态保证环形覆盖不会把未读的数据给顶掉。磨损均衡的逻辑是环形覆盖的天然副产品因为写指针依次递增轮转遍历所有扇区每个扇区擦除次数基本一致。遇到个别坏块我在擦除后做一次“写零校验”连续多次失败就把扇区标记为坏跳过它继续往后走。这个机制虽然简单但在温度变化大的工业现场很值钱避免整盘瘫痪。掉电恢复也要专门做我的做法是每个日志头带一个序号启动时扫描最近的完整日志序号不连续就说明上次掉电时写到一半直接丢弃那不完整的尾巴。这套“日志加序号”的恢复机制写起来不复杂但能把掉电损坏概率从“必然”降到“几乎不可能”。4.4 SD卡掉电检测和文件系统必坑SD卡这一块我把FatFS的f_mount放在上电初始化里但刻意延迟到系统完全就绪后才真正挂载避免跟EEPROM参数恢复抢总线。挂载失败时不要反复重试先检查卡是否在位再尝试重新初始化SDIO时钟频率。有些杂牌卡在高速模式下第一次握手失败降速到SPI模式反而能读出来这类兼容性逻辑要写进代码不然现场换张卡就不工作。写文件时我严格要求每个文件写完后立刻f_sync()跑批数据每攒够512字节也flush一次。简单说就是在FatFS里文件缓存不落盘数据就不算数。掉电前的中断处理函数我会做优先级极高但处理极短的操作拉低SD卡片选发命令让卡进入空闲态再f_sync()。实测这样能保证最近一次写入不丢也不会损坏FAT表。SD卡拔插检测我是用卡座的CD引脚接STM32外部中断实现的。检测到拔卡时先停止所有写任务并标记文件系统为“繁忙”等再次插卡重新挂载。千万别在写文件过程中处理拔卡中断那会让文件系统状态彻底乱掉大文件写入时突然拔卡基本必丢数据。5. 实测中的坑与排查实录5.1 系统性临界问题EEPROM页写陷阱我在自己板子上调试参数保存的时候发现一个诡异现象参数表前64字节能正确保存后面的一旦修改保存重启后读出来的值是乱的。排查第一反应是I2C地址或页写时序问题逻辑分析仪抓波形后确认写入地址正确但写入过程中存储区会溢出。最后定位到跨页写问题——AT24C128页写不能跨页超出页边界会回卷覆盖。这个坑在规格书里其实写得很明白但大部分人都不会专门去算“我的结构体能对齐到页边界吗”。教训就是设计参数结构体时就要让结构体大小是EEPROM页大小(64字节)的整数倍或者拆分写入单位两边都要对。5.2 静电与热插拔SD卡文件系统被破坏有次现场反馈说设备频繁重启后SD卡里的历史文件打不开读完目录直接报错。排查过程很长最后发现是SPI模式的SD卡片选引脚在热插拔瞬间产生毛刺导致主控误操作符。处理办法是在卡座电源脚串联一个磁珠和100µF电容对毛刺形成滤波同时软件上做热插拔检测的消抖延时检测到CD信号变化后先等200ms再重新挂载。从那以后同类问题再没出现过。工业现场静电打坏SD卡的事情有时候不是卡的问题是板子缺一道保护。5.3 时序坑NOR Flash 4字节地址W25Q64容量是8MB理论上只需要24位地址但我实际用FPGA读的时候发现部分扇区读出来全是0xFF写进去再读却是对的怀疑是地址选通问题。后来查手册发现这类NOR Flash在3字节模式下访问高地址没问题但部分批次固件版本对4字节地址命令响应异常。解决办法是统一用标准SPI读命令0x03并且强制使能4字节地址模式发B7命令把地址缓存成4字节。这个坑不做FPGA和MCU双端联调很难发现属于典型的“两方都觉得自己对数据就是不对”的案例。5.4 双MCU交互时的竞争问题STM32和FPGA之间通过并口总线交换数据刚开始我用一个简单握手信号FPGA请求、STM32应答。后来发现上位机同时触发“保存参数”和“读取历史曲线”时系统偶发卡死。排查后确认FPGA在写NOR Flash的同时STM32也在读NOR Flash总线访问冲突握手信号因为忙标志没清除而僵住。解决办法是把存储访问做成统一仲裁加信号量保护所有存储读写操作串行化。一个设备里两个处理器访问同一份存储必须有一个中央入口不能各干各的。6. 实操经验总结与效率提示回头把这套方案跑顺最大的体会是存储设计一定要放在系统架构层面考虑不能等硬件回来再补。数据分级、介质选型、掉电机制、双处理器协同这些在画原理图之前就要定下来否则后面每加一个存储需求都要动一堆电路和代码。具体到编码实现顺序我的建议是先写EEPROM参数管理因为参数是其他功能的前提再写NOR Flash日志器最后挂SD卡文件系统。每一步都要有独立的单元测试比如专门写一个测试工装循环写读EEPROM几千次验证寿命和掉电恢复逻辑。等三个存储层都稳了再叠加FPGA联调这样排查问题的时候总能有一层是可信的基线。如果你也在做类似控制器我可以把关键电路参数和代码结构给出来参考EEPROM选AT24C128或AT24C256NOR Flash选W25Q64或W25Q128SD卡走SDIODMAFatFS电源掉电检测用比较器加1000µF大电容各存储层之间用CRC32校验兜底。按照这个架构至少能保证设备在现场运行三五年不出现“存不上数据、丢了配置”这种低级但致命的故障。存数据这事真的不能靠运气。