STM32+FPGA工业控制器三级存储架构：EEPROM、NOR Flash与SD卡分级规划

做工业控制器设计这几年存储方案我换过不少路子。遇到过调试三个月、上位机软件升级一次控制器参数全丢的事故也遇到过SD卡用着用着目录区损坏日志全废的情况。后来在一套STM32FPGA的控制器上我把数据通盘重新规划了一遍按频率、容量、可靠性三个维度拆成了EEPROM、NOR Flash、SD卡三级存储跑了几十台设备之后这套方案基本稳定了今天就把这个过程完整复盘一下。这套方案的适用场景很明确以STM32为主控、FPGA做前端数据采集和时序控制的工业控制器需要保存的参数类型不止一种——既有高速变化的运行数据又有频繁改写的工艺参数还有成百上千条不能丢的历史日志。如果你也在做类似的板卡或者正在纠结“数据到底放哪个存储器里”这篇东西应该能帮你省下一两个月的弯路。先放结论不是Flash不能用也不是SD卡不靠谱而是工业控制器的数据天生就该分门别类地存。EEPROM放小参数NOR Flash放固件和配方SD卡放大批量日志三者各管一摊才不会互相拖后腿。1. 先想清楚一个问题为什么需要“分级”存储我在不少项目里见过一种偷懒的做法板子上焊一颗W25Q128什么数据都往里扔——参数掉电保存也写它程序升级也写它运行日志也往里塞。结果就是这颗Flash的寿命被反复擦写消耗得非常快而且一旦某次写入过程中断电固件区和参数区在同一个介质上两个一起坏哭都来不及。工业控制器的数据其实可以分成四类每一类的特点都不一样配置参数类伺服增益、温度报警阈值、IP地址这类单条数据小几字节到几十字节但改写频繁。今天调试改一下明天现场调一下一年下来可能擦写几千上万次。固件与配方类程序镜像、工艺配方、字库向量单条数据大但是改写的频率极低只有远程升级或者导入新配方的时候才动一次。运行日志类电压曲线、温度历史趋势、故障事件记录数据量大得惊人一台设备连续跑一个月几十万条记录轻轻松松。临时数据类运行过程中需要快速暂存的中间量断电可以丢但实时性要求高。把这三类数据放在同一个介质上是用一种介质去迁就完全不同的需求结果必然是只要其中一类数据的量上来了整体可靠性就跟着下降。分级存储的本质就是让每一种介质只处理它最擅长的那类数据。1.1 三种存储介质的核心差异对比维度EEPROMNOR FlashSD卡单条容量几KB~几十KB几MB~几十MB几GB~几十GB擦写单位按字节按扇区4KB/块64KB按块512B/4KB擦写寿命约100万次约10万次标称约10万~50万次实际看品质写入速度慢ms级/页中等页写约0.5ms较快可达MB/s级掉电安全性最好字节级原子性中等受制于扇区擦除最差文件系统易损应用定位频繁改的小参数低频改的大块数据海量日志、历史数据把差异列出来就一目了然了。EEPROM擦写寿命最长、掉电安全最好但容量小适合放需要频繁改而且绝对不能丢的参数NOR Flash按扇区擦写、容量中等正好做固件区和配方区SD卡容量大、吞吐能力强缺点是最怕写一半断电导致文件系统损坏但只要我们做好分文件轮替和掉电防抖这个缺点完全可以接受。1.2 这套方案选型的真实考量有人会问参数为什么不也放NOR Flash里答案很简单NOR Flash的寿命只有十万次量级如果一个参数一天被改写二十次一年下来就七千多次十年后必然逼近寿命极限。而EEPROM标称百万次同样的改写频率撑一百年都没事。同理日志为什么不塞NOR Flash因为日志量太大几十MB的Flash记录不了几天就满了SD卡才是它的主场。还有一点容易被忽视分级之后即便某一颗存储器件挂了也不会牵连另外两类数据。固件区的Flash坏了至少EEPROM里的参数还在SD卡里的历史日志还能导出来。这对售后定位问题有非常大的帮助。2. 存储架构设计FPGA抓数据STM32做决策明确了三级存储之后紧接着就要解决“数据从哪来、走哪条路到存储介质”。这套方案里STM32和FPGA的分工是FPGA管高速采集和时序同步STM32管协议解析、空间分配和最终落盘。为什么要这样切因为工业控制器面对的信号不止一路——编码器反馈、模拟量采集、总线通信各路数据的速率和时序都不一样。如果全让STM32去处理光中断就能把它干趴下。FPGA天生适合并行处理这些高速数据流采集完的数据放进内部FIFO或者双口RAMSTM32按需要主动去搬两边互不阻塞。我的数据流是这样的传感器/总线数据进入FPGAFPGA按协议解析、滤波、打时间戳送入片内FIFO。STM32通过FSMC或SPI从FIFO读取数据先做数据合法性检查再分类路由。需要长期保存的运行数据按一定周期组包写入SD卡的日志文件云端需要上报的走以太网或4G模块。需要掉电保存的工艺参数通过I2C写入EEPROM写入前先比较新旧值避免无效写入。2.1 存储空间划分建议我把一个实际的Flash分区表贴出来这个是调试过多次之后定型的方案可以直接参考区域地址范围用途说明Bootloader0x000000~0x00FFFF引导程序永不更新保证整机可恢复App A0x010000~0x0FFFFF主程序固件正常运行区App B0x100000~0x1FFFFF备份固件升级失败可回退配方区0x200000~0x20FFFF工艺配方低频写入按版本管理参数备份区0x210000~0x210FFF关键参数镜像与EEPROM做双备份EEPROM这边我分了三个逻辑区域系统参数区、校准参数区、运行计数区。系统参数区放设备ID、通信地址这类出厂后基本不变的基础信息校准参数区放变送器校准系数这个字段会频繁改写运行计数区记录累计运行时间和开关机次数写入频率不算高但属于寿命敏感型数据。2.2 为什么不让FPGA直接操作存储介质这里要重点说一个我的教训。最早一版设计为了让数据从FPGA直接落盘到NOR Flash我把Flash的控制器逻辑全部在FPGA里做完了——SPI状态机、坏块管理、擦写均衡全写了。结果呢光是调试擦除和写入状态机就耗了两周踩了一堆雷。后来想明白了FPGA做底层驱动完全没有必要存储协议栈文件系统、擦写策略、磨损均衡本来就是MCU的强项FPGA要干的活是把数据又快又准地送到STM32手里。千万别在FPGA里硬啃FAT文件系统。SD卡的文件系统读写STM32上跑FatFS成熟稳定调试工具多问题也好定位。FPGA里顶多做个I2C接口去读写EEPROM那都算多的。分工越清晰系统越稳。3. EEPROM实操I2C时序、页写限制与磨损均衡EEPROM这个环节最常见的芯片是AT24C系列容量从2Kbit到512Kbit都有。我选的是AT24C25632KB容量I2C接口正好覆盖参数存储的所有需求。它的设备地址是0xA0A0~A2引脚接地点不同地址会变写周期tWR典型值5ms页大小64字节。这些参数看着平淡但每个都埋着雷。3.1 I2C读写EEPROM的关键细节第一个坑是页写越界。AT24C256每页64字节连续写多个字节时地址必须在页内连续。假如当前地址是页内偏移62字节你要写4个字节这4个字节跨过了页边界控制器会把后面两个字节打回这一页的开头覆盖掉已有的数据。这个行为不同厂家的芯片可能略有差异但本质都一样——分页操作必须自己做。我封了一层写入接口逻辑是这样的每次写入前先算当前地址到页末尾还剩多少字节如果剩余字节不够这次的数据长度就先写一部分地址换到下一页再续写。用起来就是下面这个样子uint8_t AT24C_WritePage(uint16_t devAddr, uint16_t memAddr, uint8_t *pData, uint16_t len) { while (len 0) { uint16_t pageRemain AT24C_PAGE_SIZE - (memAddr % AT24C_PAGE_SIZE); uint16_t chunk (len pageRemain) ? len : pageRemain; I2C_Start(); I2C_WriteByte(devAddr); I2C_WriteByte((memAddr 8) 0xFF); I2C_WriteByte(memAddr 0xFF); for (uint16_t i 0; i chunk; i) { I2C_WriteByte(pData[i]); } I2C_Stop(); // 等待芯片内部写周期结束轮询ACK while (!AT24C_WaitWriteComplete(devAddr)); memAddr chunk; pData chunk; len - chunk; } return 1; }写完一定要等tWR结束再发起下一次操作。芯片在内部写周期内不响应ACK可以利用这一点做查询——发送设备地址时芯片会返回NACK就继续等直到它回ACK。千万别用固定延时温度、电压不同实际写周期会有波动轮询最可靠。第二个坑是修改单个字节也要整页读出再写回。因为EEPROM只能把1写成0想把某个bit从0改回1必须先擦除。EEPROM的“擦除”就是整页写入0xFF。所以正确做法是读整页到RAM在RAM里修改目标字节再把整页写回。我这里说的参数管理框架里每个“参数块”固定64字节长一页正好放一块从不跨页省掉了很多麻烦。typedef struct { uint16_t magic; // 有效标识 uint16_t version; // 参数版本 uint8_t data[60]; // 实际参数区 uint8_t crc; // 简单校验 } ParamBlock_t;3.2 EEPROM磨损均衡与双备份EEPROM寿命长不代表可以随便造。我最开始直接按固定地址写结果调试阶段三天就写废了一片AT24C256——后来才反应过来反复改同一个参数固化的页一直在被擦写而绝大多数页一次都没动过。解决办法是做一个环形磨损均衡把参数区切成64个页一个逻辑参数块不是固定在某一页而是用一个索引表记录当前有效块在哪个页写一次就往下挪一页到头再绕回起始位置。这么一来一百万次写入被摊到64页上每页实际只承受约一万五千次擦写相当于整体寿命提高了64倍。双备份的思路更直接关键参数在EEPROM里存两份一份在地址高位一份在低位。写入时先写第一份再写第二份上电读取时先读第一份做CRC校验失败再读第二份。如果两份都失败就恢复出厂默认。这个机制救过我一回有台设备现场断电瞬间写参数第一份数据写了一半靠第二份完好数据兜住了之后的软件版本里我就把这个逻辑固化下来了。4. NOR Flash实操SPI指令流程与固件AB双区NOR Flash在工业控制器里最主要的用途是放固件镜像。我用的是W25Q12816MB容量SPI四线接口。SPI模式的好处是引脚少、适配性好、任何带SPI外设的MCU都能驱动成本也低。读速度相比并行NOR要慢但在固件升级场景中完全够用。4.1 操作NOR Flash的标准流程NOR Flash的读写不像EEPROM那么直观四个基本命令必须烂熟于心0x06 写使能WREN每一次写操作之前都要发漏了命令直接不执行。0x03 读数据给定24位地址连续读任意长度最快54MHz。0x02 页编程Page Program每次最多256字节目的地必须在同一页内。0x20 扇区擦除Sector Erase擦除一个4KB扇区擦完变0xFF耗时典型值几十到几百毫秒。写数据前必须保证目标扇区已经擦除过这是新手最容易犯的错。还有一个细节发完写命令后要轮询状态寄存器0x05读状态寄存器的WIP位等它从1变成0才能进行下一次操作。不是延时一下就算完擦除时间受温度和电压影响很大轮询才是稳妥的。// 等待Flash空闲 void Flash_WaitBusy(void) { SPI_CS_LOW(); Flash_SendByte(0x05); // 读状态寄存器命令 do { status Flash_SendByte(0x00); // 读取状态值 } while (status 0x01); // WIP位为1表示忙 SPI_CS_HIGH(); } // 固件写入先擦除再编程每块都等完成 uint8_t Flash_WriteFirmware(uint32_t addr, uint8_t *pBuf, uint32_t len) { Flash_WaitBusy(); Flash_SendCommand(0x06); // WREN SPI_CS_LOW(); Flash_SendByte(0x02); // Page Program Flash_SendAddr(addr); for (uint32_t i 0; i len; i) { Flash_SendByte(pBuf[i]); } SPI_CS_HIGH(); Flash_WaitBusy(); return 1; }4.2 固件升级的AB双区与掉电保护固件升级最怕什么设备升级到一半断电固件区只写了一半下次上电系统连引导程序都进不去。我的做法是固件区拆成App A和App B两个分区Bootloader永远不动。升级时先把新固件完整写入App B校验成功后把A/B切换标志位写入EEPROM再重启加载App B。如果写入过程中断电App A还是完好的Bootloader检测到切换标志未生效直接回退加载App A设备照常运行。提示升级失败回滚这件事一定不要依赖应用代码做到而是Bootloader的职责。Bootloader的唯一任务就是检查升级标志、选择加载A还是B。它本身越简单越可靠升级成功后再跳转不要有太多花活。4.3 Flash磨损均衡的简化方案在固件场景Flash的十万次擦写寿命本来就很充裕固件一年升级个几次算高频了。但配方区如果也存在NOR Flash里就必须做均衡。我的配方区用了64个扇区循环做法和EEPROM一样写新版本配方时写到当前扇区的下一个更新索引表旧扇区不急着擦等循环回来再擦。这样做有两个好处一是把擦写摊匀延长寿命二是天然保留上一版本万一新配方有问题还能回滚。5. SD卡实操FAT文件系统写入与掉电保护SD卡是这套方案里存储量最大的层级主要放运行日志和历史趋势数据。我在STM32上是把SD卡跑在SPI模式下的——虽然SDIO模式速度更快但SPI模式兼容性最好几乎任何STM32都能驱动而且日志写入速率几十KB/s就够了SPI模式完全满足。四根信号线CS、CLK、MOSI、MISO接上就能跑调试也简单。5.1 SD卡初始化与写入的注意点SD卡初始化有一个必须遵守的时序上电后至少要发送74个时钟周期10字节0xFF让卡完成内部上电过程。之后依次发CMD0进入SPI模式、CMD8检查电压范围、ACMD41初始化、CMD2读CID、CMD3读RCA最后CMD7选中单卡。任何一步不通就从头再来有些劣质卡要重试三四次才能过去所以初始化循环的重试次数别设得太少。我遇到过“SD卡内部寄存器锁死”的情况——某次测试时意外拔卡重新插上后初始化过不去发送CMD0也不返回0x01似乎卡完全不响应了。后来排查下来是卡内部进入了保护状态寄存器状态被异常操作污染了。解决方式很笨但有效断电把卡从板子上拔下来用一个读卡器插到PC上让PC重新初始化一次再拔下来插回板子就恢复正常了。这说明SD卡的硬件状态是可以被外部异常操作搞乱的单纯复位程序可能不够需要一次“全新上电初始化”来恢复。所以在产品设计上SD卡的卡槽一定要用带检测脚的检测到卡片拔出时要及时停写别让日志程序拼命往一个不存在的设备上写数据那样最容易把卡写坏。写入日志时我用的是FatFS库但这里有个坑必须说f_write之后数据其实还在Cache里要f_sync之后才真正落到卡上。如果每隔几百条记录就f_sync一次写入效率会很低但如果不f_sync掉电就会丢失最近几十条数据。我的经验是把日志打包成一条一条记录每凑够一个扇区大小512字节再f_sync一次这样既保证效率掉电丢失的数据量也控制在一两个扇区以内完全够用。// 日志写入满一个逻辑块才落一次盘 void Log_WriteBlock(void) { UINT bw; f_open(logFile, 0:/RUNLOG.LOG, FA_WRITE | FA_OPEN_ALWAYS); f_lseek(logFile, currentOffset); f_write(logFile, logBuffer, 512, bw); f_sync(logFile); // 强制写入SD卡 f_close(logFile); currentOffset 512; }5.2 日志文件的轮替策略日志文件不能打开一个文件从头写到尾那样SD卡总有一天会被写满而且单个文件过大FatFS操作起来也麻烦。我做的是日志文件轮替每天生成一个日期文件比如“LOG20250101.txt”跨天之后自动创建新文件。再配合数量控制全局只保留最近90天的日志超出就删除最老的文件。这样SD卡的空间永远不会塞满现场工程师导出日志也直观按日期找就完了。有一个细节不要频繁地对同一个文件做打开关闭操作。FatFS的目录项更新和FAT表更新都有开销长时间运行后容易在目录区累积碎片。我的做法是一个文件写够设定大小后就不再打开它下次直接开新文件避免反复打开同一个文件引起目录区大面积改写也减少了目录区损坏的概率。6. 常见问题与排查速查表调试这套存储架构的过程中我积累了一些典型的坑直接整理成速查表遇到问题照着查就行现象可能原因排查方法EEPROM写入没反应I2C一直NACK写周期未结束WP写保护引脚被拉高检查WP引脚电平用逻辑分析仪抓I2C时序EEPROM写入字节被覆盖成0xFF页写跨页边界未做分页处理确认页大小写入前计算页剩余空间NOR Flash读取全0xFF扇区未擦除SPI时钟极性/相位配置错误发0x90读制造商ID验证通信检查擦除命令是否执行NOR Flash写使能不生效0x06命令后没有等待WIP变低就发下一条指令轮询状态寄存器确认WIP0再进行写操作SD卡初始化超时CMD0时序不对上电初始终化不够卡处于锁死状态增加初始化前时钟个数检查CMD8/ACMD41返回拔卡用PC格式化一次SD卡日志丢数据f_sync频率太低拔卡时机不对每次日志落盘都要f_sync软件加卡检测中断固件升级后起不来App区的镜像校验没通过AB区切换标志异常确认启动标志在EEPROM里的校验值保留Bootloader日志输出串口参数区数据全乱EEPROM磨损均衡索引表损坏写了一半断电双备份CRC校验优先从第二备份恢复排查的时候示波器和逻辑分析仪是两大神器。I2C时序问题ACK、起始停止条件用逻辑分析仪抓波形一次就能看清SPI的时钟极性和相位不对时读回来的数据会变成0xFF或者乱码先读芯片的JEDEC ID制造商ID能读出来就说明通信通了再去排查别的。别一上来就怀疑芯片坏了九成都是时序配置的问题。关于SD卡根目录授权很多开发者在电脑端调试会遇到类似问题——系统提示无法对SD卡根目录授权导致文件访问失败。板卡上虽然没有这个图形界面授权流程但本质是一致的FAT文件系统对根目录和分区是有访问控制的最稳妥的解决办法就是把日志文件放在独立子目录下不要在根目录裸写文件坏根目录的故障率要低很多。还有一个被很多人忽略的EEPROM和NOR Flash的硬件连线。EEPROM的WP引脚和NOR Flash的WP引脚都要看具体情况有些设计把写保护引脚直接接地没问题有些设计接了GPIO那上电的时候如果GPIO默认输出高就会把整个存储芯片置于写保护状态初始化时读正常、写不进去这种隐蔽故障能折磨你一整天。尾声这套STM32FPGA三级存储方案我在实际项目里用下来的最大体会是存储设计不能等到硬件定型了才想它应该在系统架构阶段就和处理器选型、数据流分析同步做规划。把每一种数据分类好、对应好存储介质后续的固件升级、数据导出、故障恢复全都是顺水推舟的事反过来如果一开始就想着“反正有个Flash全往里塞”后面的每一个功能可能都在给存储系统埋雷。最后再分享一个小经验无论是EEPROM的磨损均衡还是NOR Flash的扇区轮换这类代码一定要在项目早期就写进基础库不要等现场出问题了再补。数据存储这种东西问题往往要等设备跑几个月、写几十万次之后才会暴露到那时候再改成本就高了。前期多花两天打地基后期能少加三个月的班。