工业控制器这东西我在产线上碰过不少也在售后电话里听过不少惨案一台设备跑着跑着参数全部丢失伺服上电就乱撞日志写不进SD卡故障原因无从追溯固件升级到一半断电控制器直接变砖。这些问题十有八九都出在数据存储设计上。这篇硬件篇·12就把STM32FPGA架构下最常用的分级存储方案——EEPROM、NOR Flash、SD卡——彻底讲清楚为什么三种介质要同时用、各自负责什么数据、硬件上怎么接、驱动和写入策略怎么做以及调试现场踩过的坑。内容偏向运动控制、数据采集终端、小型PLC这类设备基本覆盖了工业控制器存储的主流需求。1. 存储需求拆解分级方案的出发点是数据属性1.1 工业控制器里到底要存什么数据很多朋友上来就问“用EEPROM还是NOR Flash”我一般会反问一句你的数据是什么属性因为工业控制器里要存的东西属性差异非常大粗暴地统一用一种介质不是容量不够就是可靠性出问题。以我做过的一台多轴运动控制器为例需要存储的数据可以分成三大类。第一类是系统参数包括PID增益、限位位置、编码器方向、设备序列号、通信地址、校准系数等。这类数据量很小几十字节到几KB但价值极高。它们变化频率不高只在调试、校准或现场调整时改写可绝对不能丢。参数一旦丢失设备轻则报警停机重则机械结构直接撞坏。第二类是固件与配置镜像包括STM32的应用程序镜像、FPGA的bitstream、字体库或配置文件。量级在几百KB到十几MB更新频率很低一年几次但读取频率很高因为设备每次上电都要加载它们。这类数据要求能够快速、可靠地整块读取更新时又要能整体替换。第三类是运行日志包括故障码、报警记录、带时间戳的温度曲线、实际运行统计等。这部分数据量很大一台设备一天产生几十MB日志很常见。写入频率极高每次采样或每秒钟都会追加记录。日志的价值在于追溯问题丢失最后几秒甚至几分钟可以接受但整个文件系统不能损坏。三类数据的特性完全不同参数数据量最小但可靠性要求最高固件要求读取性能和可更新性日志要求容量和持续写入能力。把它们混在一种介质里必然顾此失彼。1.2 为什么不能“一块大Flash全搞定”有人说我直接挂一块大容量NOR Flash甚至NAND分层分区不也能存所有数据吗理论上是实际上坑很致命。关键在于写入粒度。EEPROM可以按字节改写简直是“随时改一小点”的理想介质NOR Flash虽然可以随机读但写入前必须先擦除整个扇区4KB的扇区擦除一次要上百毫秒。你为了修改一个字节的PID参数得先把整个扇区读出来、改好、整扇区擦掉、再全写回去。要是这个过程中断电整个扇区的数据全部报销。NAND Flash更复杂它按页读写物理坏块多管理算法复杂在工业控制器里用来存关键参数完全是自找麻烦。所以标准工业方案就是把三种介质各司其职关键参数进EEPROM代码和FPGA镜像进NOR Flash日志大数据进SD卡。这不是拍脑袋而是在可靠性、容量、寿命、成本、开发周期之间反复权衡后的结果。2. 存储介质选型从底层原理到接口选型2.1 EEPROM几十字节参数的核心保险柜EEPROM为什么能按字节写因为它每个存储单元除了浮栅管之外还多做了一个用于选通控制的晶体管可以独立擦除和编程每一个字节。代价是单位面积大容量做不了太大市面上主流也就几Mb但这对存参数来说完全够了。我项目里最常用的器件是AT24C256容量256Kbit也就是32KBI2C接口支持64字节页写工业级工作温度-40~85℃擦写寿命标称100万次数据保持能力在40年以上。这些参数对参数存储来说每一项都够用又留有余量。接线时要注意两个点。第一I2C总线上拉电阻我习惯用4.7kΩ不要用10kΩ太大线电容一大波形就变差。第二AT24C256有WP写保护引脚我会把它直接接高电平硬件上禁止意外写入。这个设计在实战中救过我一次后面调试实录里细说。选型还有一个容易被忽略的点同样是“256”后缀AT24C256和AT24C02的页大小完全不同AT24C02一页只有8字节如果按64字节去写数据会回绕覆盖到当前页起始位置属于经典的“看着能写其实是错的”。所以一定先看数据手册确认页大小。2.2 NOR Flash固件和比特流的可靠仓库NOR Flash和EEPROM本质上是同一种浮栅工艺家族但结构上每个单元只有一个晶体管省掉了字节级选通管密度上去了代价是只能按扇区擦除。它最大的优势是随机读取极快且支持XIP就地执行STM32可以直接从NOR Flash映射地址运行代码不过大多数项目里还是会把固件拷贝到RAM跑。我常用的NOR Flash芯片是W25Q128128Mbit也就是16MBSPI接口4KB扇区256字节页编程擦写寿命约10万次。20MHz SPI时钟下实测读速度能到2MB/s以上做固件加载绰绰有余。选16MB容量是因为它同时要装STM32固件镜像和FPGA的bitstream还要留出版本回滚区。NOR Flash有个特性要记住它不像EEPROM那样能字节擦除擦除最小单位是4KB扇区而且擦除操作一旦开始不能中断大概需要150ms。如果恰好在这个窗口断电这个扇区可能处于“半擦半写”的诡异状态。所以稍微像样点的工业设计都会在NOR Flash里做双镜像备份或者至少有一个“启动头校验和”结构确保启动加载时能判断镜像是否完整。2.3 SD卡日志大数据仓库同时也是最脆弱的环节SD卡从物理结构上看就是一个微型控制器加NAND Flash对外通过CMD/ACMD指令操作。好处是容量大、即插即用、可更换坏处是内部FTL、磨损均衡、坏块管理全都是黑盒。你在应用层写一个文件它内部怎么搬运数据、怎么更新FAT表你完全看不见。这种黑盒在工业场景里非常头疼。掉电瞬间SD卡控制器内部SRAM里可能还有没落盘的缓存数据FAT表条目和文件数据更新顺序也没法保证轻则丢最后一段日志重则文件系统整个挂掉。工业级SD卡会做掉电检测和更强的缓存管理但价格是消费卡的好几倍而且同样存在坏卡风险。我的实际策略是日志数据用普通SD卡但在软件层面做好缓冲、定期同步、日志文件大小滚动并且明确告知用户“这张卡是消耗品”。关键参数绝不落SD卡这是铁律。2.4 三种介质关键参数对比介质典型容量写入粒度擦写寿命常用接口掉电可靠性典型型号EEPROM2Kb~2Mb字节约100万次I2C/SPI高AT24C256NOR Flash8Mb~256Mb扇区4KB约10万次SPI/QSPI中需防擦除断电W25Q128SD卡128MB~数GB扇区512B依赖内部FTLSDIO/SPI低各类工业卡适用数据参数/配置固件/bitstream日志/大数据---3. STM32FPGA硬件架构谁管存储怎么接3.1 数据流划分FPGA专注采集STM32统一管存储在STM32FPGA的架构里我最推荐的做法是让STM32当存储的总管家所有EEPROM、NOR Flash、SD卡全部挂在STM32的I2C、SPI和SDIO总线上。FPGA专心做它擅长的事高速信号采集、编码器计数、ADC采样、滤波算法、相控阵相位控制这类实时任务然后把处理结果或原始数据通过内部FIFO缓存用SPI或并行总线交给STM32。这个分工不是随便拍的。FPGA里写SD卡协议栈和FAT文件系统资源开销很大调试起来极痛苦而且FPGA每改一版逻辑还要重新验证存储时序工作量大到难以承受。反过来STM32生态里有成熟的HAL库、CubeMX、FatFS移植挂个SD卡半天搞定所以这种“FPGA采集STM32存储”的架构开发效率和稳定性都最好。有一次做10Msps、16位的ADC采集项目原始数据率是20MB/sSTM32的SDIO实测写速虽然能到20MB/s但STM32同时还要跑通信协议和运动控制CPU占用极高。最后我改成在FPGA里先做降采样和特征提取把10Msps原始数据抽成每秒几千个特征点STM32再落盘压力瞬间消失。这就是FPGA存在的意义之一不是所有数据都需要原样进存储。3.2 具体接口分配以STM32F4为例以我常用的STM32F407为例接口分配可以这样规划EEPROMAT24C256挂I2C1SCL在PB6、SDA在PB7两颗4.7kΩ上拉电阻到3.3V。A0/A1/A2地址引脚都接地WP引脚接高电平禁止误写。NOR FlashW25Q128挂SPI2SCK在PB13、MISO在PB14、MOSI在PB15片选CS用PB12。WP#和HOLD#引脚直接接3.3V防止调试时被意外拉低导致写保护或挂起。SD卡用SDIO接口4位数据模式。CLK在PC12、CMD在PD2、D0-D3在PC8-PC11。高速读写需要20MB/s以上时别用SPI模式驱动SD卡SDIO才是正道。掉电检测用STM32内置PVD可编程电压检测器通过库函数配置在2.9V触发中断并设为最高优先级。当主电源掉电时MCU的3.3V还靠大电容撑着能争取几十毫秒黄金时间。硬件连好之后还有一个容易被忽略的点SDIO的CLK线上如果布线过长最好加33Ω串联电阻否则高速读写时序容易出错而且这种错误很随机找起来特别费劲。3.3 FPGA的bitstream到底放哪里FPGA本身是SRAM型器件掉电就丢配置所以它需要一份外部配置源。最传统的方法是用专用配置芯片EPCSFPGA上电自己加载不依赖外部MCU。但EPCS容量固定、采购渠道窄、远程升级不方便所以我在多数工业控制器项目里改用“NOR FlashSTM32被动配置”方案。具体做法是FPGA的bitstream文件预先通过STM32写入W25Q128的固定区域上电后STM32先从NOR Flash把bitstream读出来再按FPGA要求的被动串行或selectMAP时序把数据逐字节送进FPGA配置引脚。这样做的最大好处是远程升级非常灵活STM32可以从SD卡或网络拿到新bitstream先写进NOR Flash再复位FPGA重新加载几秒钟完成现场升级不用拆机不用编程器。代价是上电后FPGA要等STM32先把程序跑起来才能配置启动延迟比EPCS长几十毫秒。对绝大多数工业设备来说这点延迟完全无所谓但如果有“上电立即要输出”的严格要求就得换回主动配置方案。3.4 掉电检测与供电保持电路工业现场电源毛刺多、断电不讲道理所以掉电保护是存储设计里最不能省的一环。我的标准做法分三层一是PVD检测到电压跌落后STM32立即进中断把还在RAM里的关键状态和未落盘的参数以最快速度写进EEPROM二是在EEPROM里做一个事务标志比如“写入开始前先把事务ID标记为未完成全部写完后改成完成”下次上电一看标志就知道上次写入是否完整三是用一个大容量电解电容或超级电容让MCU在断电后能多撑几十毫秒覆盖最关键的一次参数落盘。电源保持电路的具体容量可以用电流乘时间来估算。假设系统掉电后还需要3.3V/200mA工作20ms那么需要提供的能量是0.2A×0.02s0.004C也就是至少4000uF电容在允许压降范围内释放这么多电荷。实际工程里我会留两倍余量用1000uF到2200uF的电容效果也不错具体看你系统功耗。4. 驱动实现与写入策略代码背后的设计思路4.1 EEPROM驱动I2C页写和神奇的5ms等待STM32CubeMX生成I2C初始化之后向AT24C256写数据其实就一行核心调用但要理解背后的时序。AT24C256的7位从机地址是0x50因为A0/A1/A2接地转换成8位写地址就是0xA0读地址0xA1。// 向EEPROM地址0x0000写入32字节 uint8_t buf[32] {0}; HAL_I2C_Mem_Write(hi2c1, 0xA0, 0x0000, I2C_MEMSIZE_8BIT, buf, 32, 100);写完这行之后AT24C256内部要进入写周期典型时间5ms。在这5ms内EEPROM对I2C总线上的任何命令都不响应表现为从机不拉低ACK。如果你继续发命令只会得到NACK。最稳妥的等待方式是不断发一个零长度的写命令直到EEPROM回ACK表示内部写周期结束。这是I2C设备手册里明确推荐的做法比固定delay更可靠因为不同批次、不同温度下写周期时间有差异。页写回绕是另一个常见的坑。AT24C256的页大小是64字节也就是说一次最多连续写64字节而且这64字节必须在同一个页内。如果起始地址在页的尾部比如地址0x003F你写4字节它会写到0x0040吗不会它会回绕到0x0000去所以跨页写必须由软件拆分。写参数表时我习惯要么把参数表长度控制在64字节以内要么在函数里做页边界判断先写本页剩余空间再写下一页。写入之后回读校验也很有必要。I2C时序边缘情况下数据可能无声无息地写错回读一遍整表并比较CRC比任何理论论证都让人放心。4.2 NOR Flash驱动SPI命令序列和固件双镜像升级W25Q128的SPI操作很直接但要严格按命令时序来。先发0x9F读制造商和设备ID确认芯片在然后发0x06写使能接下来可以页编程0x02或者扇区擦除0x20最后轮询状态寄存器0x05等待WIP位bit0清零。uint32_t nor_read_id(void) { uint8_t tx[4] {0x9F, 0x00, 0x00, 0x00}; uint8_t rx[4] {0}; HAL_GPIO_WritePin(FLASH_CS_PORT, FLASH_CS_PIN, GPIO_PIN_RESET); HAL_SPI_TransmitReceive(hspi2, tx, rx, 4, 100); HAL_GPIO_WritePin(FLASH_CS_PORT, FLASH_CS_PIN, GPIO_PIN_SET); return (rx[1] 16) | (rx[2] 8) | rx[3]; // 高字节是厂商ID }真正的难点在固件升级流程。直接擦旧写新一旦断电就是砖头。我在多个项目里反复验证过的双镜像流程是这样的Bootloader位于NOR Flash固定起始区域上电先读启动头里面保存“当前有效版本号”和版本对应的起始地址、长度、CRC。新固件通过SD卡或串口上传后先写入另一块空闲区域写完后整体回读校验CRC。校验通过后更新启动头里的“有效版本”指针指向新镜像更新完这个指针瞬间才算是升级完成。下次上电Bootloader按指针加载新镜像。如果指针没更新成功继续加载旧镜像。这套流程写起来比直接擦写复杂但它保证升级过程中任何一步断电设备都能回到一个可用版本。工业设备远程升级没有这种保护机制就等于在赌命。还要注意NOR Flash改一个字节也要整扇区重写。如果只是更新配置结构体里的某个字段正确做法是把整个4KB扇区读进RAM修改目标字节擦除扇区整扇区写回。这一步如果忘了数据就是错的而且错得很隐蔽。4.3 SD卡驱动FatFS移植和日志落盘姿势SD卡部分我强烈建议直接用FatFS文件系统库别自己造轮子。用STM32CubeMX把SDIO初始化好再下载FatFS源码配置ffconf.h里的几个开关FF_USE_LFN设为1支持长文件名FF_FS_EXFAT可以关掉工业控制器用FAT32足够兼容性更好。FF_USE_FIND设为1方便以后做日志目录遍历。日志文件的操作模式要固定。我的标准写法是f_open(file, 0:/log/data_2025.log, FA_OPEN_ALWAYS | FA_WRITE); f_lseek(file, f_size(file)); // 定位到文件末尾追加写 f_write(file, log_buffer, len, bw); f_sync(file); // 关键记录立即落盘 f_close(file);f_sync的作用是把FatFS内部的缓存数据真正刷到SD卡硬件保证文件大小和目录项是同步的。如果只f_write不f_sync数据可能还在缓冲池里掉电直接蒸发。但每次f_sync都有性能损耗所以我的策略是分两级关键故障记录、报警记录必须立即sync普通连续采样数据攒够512字节SD卡一个扇区再写一次既不浪费吞吐也控制掉电影响范围。日志文件不能无限大否则FAT表越改越频繁SD卡寿命掉得飞快。我给每个日志文件设上限比如64MB写满了自动切换新文件保留最近N个文件旧文件允许被覆盖。这样既控制容量又减少SD卡FAT区擦写频率。4.4 写入限频与磨损均衡让“100万次”真的够用很多工程师看到EEPROM标称100万次擦写寿命就觉得随便写。我算一笔账如果程序bug导致每秒写一次EEPROM100万次大约11.5天就耗尽。这还没算页擦写放大。所以EEPROM绝对不能按固定周期傻写正确姿势是只在参数值发生变化时写入而且要连续两次写入之间加最小间隔比如100ms防抖。参数区我还会做成“双份校验”结构。一份主区一份备份区写入时先写备份区并标记校验再写主区上电读主区校验不对就回退备份区。这样即使某个字节写坏了系统也能自动恢复而不是参数全丢。NOR Flash的磨损均衡我在W25Q128上做得很简单但有效日志或配置分区块循环使用一个循环计数器指示当前写到哪一块每次优先写擦写次数最少的块。对于只有10万次擦写寿命的NOR Flash配合固件低频更新寿命绰绰有余。SD卡内部的磨损均衡不是你能控制的只能靠减少写入次数和降低低频写频率前面说的“攒扇区再写”就是最重要的手段。// 配置区循环扇区写入示意 uint8_t current_sector read_config_sector_index(); current_sector (current_sector 1) % CONFIG_SECTOR_COUNT; erase_sector(current_sector); write_sector(current_sector, config_data); write_sector_index(current_sector); // 更新索引5. 调试实录那些折腾到半夜的坑5.1 EEPROM一上电就被清空凶手是WP悬空有一台控制器调试了很久EEPROM写入读回都正常但每次整机断电重启后参数全部归零。我一度怀疑是芯片质量问题换了三片都一样。后来用示波器抓掉电瞬间的I2C波形发现掉电时SDA线上有一串异常毛刺顺着毛刺查下去发现EEPROM的WP引脚是浮空的没有接任何电平。掉电瞬间I2C线上的耦合噪声让WP引脚电平波动EEPROM进入写保护解除状态同时I2C线上还有残余信号正好被当成写命令执行把数据冲掉了。修复方式非常简单WP引脚直接接3.3V硬件上永远写保护再把I2C上拉电阻从10kΩ降到4.7kΩ增强抗干扰。从此再没出现过参数被清空。这个案例之后我做任何存储电路的第一件事永远是检查WP和HOLD引脚必须接死电平绝不能浮空。5.2 NOR Flash擦除卡死SPI时钟背锅W25Q128页擦除时有一阵子总在产线上随机出现WIP位永远为1的卡死现象。排查发现SPI时钟配置到了42MHz虽然W25Q128的读命令能承受这个速度但在擦除和页编程等操作命令阶段内部状态机对时序边沿有更严格的要求时钟太快导致命令字节变形芯片进入未知状态。把SPI时钟降到20MHz擦除命令前先确保CS拉低时SCK是高电平空闲状态卡死问题彻底消失。之后我在所有项目里NOR Flash的SPI时钟都控制在20MHz以下只追求稳定不追求极限速度。还有一个看似搞笑实则危险的坑擦除过程中调试器复位了MCU。如果你在调试时单步或者复位代码正好卡在擦除流程中间NOR Flash的擦除已经开始它不管主控是否复位都会继续擦完。但你的代码不知道这个状态复位后如果直接发下一个擦除命令可能干扰内部状态机。所以调试NOR Flash代码时要么不要随意复位要么在代码初始化里加“读状态寄存器直到WIP清0”的等待。5.3 SD卡初始化失败和“寄存器锁死”热词里有人提到“sd卡内部寄存器锁死”这个我太有共鸣了。现象是设备在写SD卡日志时突然断电重新上电后SD卡要么返回错误要么完全无响应。本质是SD卡控制器掉电时正处于某种内部写状态重新上电后上电时序异常导致寄存器状态卡死。普通消费级卡尤其明显工业级稍好但也会中招。我的处理流程是上电后做完整的初始化序列CMD0→CMD8→ACMD41ACMD41轮询最多给1秒超时超时后强制进行一次电源完全断开再重新上电硬件上用MOS管控制SD卡供电再做一次初始化。实测下来绝大多数卡能救回来。如果还不行只能备份数据后格式化格式化前优先尝试用STM32的USB虚拟串口把卡里还能读的部分拷出来能救多少救多少。要更根本地降低这类问题还得回到软件策略关键日志f_sync勤快一些让数据在断电前尽可能落盘日志文件滚动写不要长期挂在同一个文件上减少FAT表目录项热区。做全套下来SD卡损坏概率至少降一半。5.4 FPGA配置加载失败GPIO顺序搞鬼用STM32被动配置FPGA时遇到过大概十分之一的概率FPGA加载失败DONE引脚始终拉不高。查了半天发现是初始化顺序问题必须在配置前先把控制引脚设为正确状态尤其要用GPIO输出模式拉低FPGA的PROGRAM_B并等待足够长的时间规格书一般要求至少2us再释放。我原本在CubeMX初始化后立刻开始发数据GPIO模式还是默认浮空输入导致FPGA误判配置时序没有开始。正确顺序是先初始化所有配置相关GPIOPROGRAM_B先拉低再拉高完成一次配置复位然后检测DONE为低表示FPGA已经等待配置最后才开始往SPI里送bitstream数据。每次配置前最好再读一次NOR Flash ID确保存储芯片正常避免在“Flash没就绪”的情况下读出一堆0xFF喂给FPGA。按这个流程改完加载失败率从十分之一降到几乎为零。5.5 存储故障通用排查顺序最后分享一套我处理存储问题的通用排查顺序几乎适用所有外设按这个顺序能少走很多弯路。第一步量硬件电平供电电压、上拉电阻、WP/HOLD引脚电平是否正确EMMC/SD卡供电是不是在标准范围内。第二步看波形用示波器抓I2C/SPI/SDIO波形确认地址和命令字节波形乱就查布线、上拉、时钟频率。第三步读IDEEPROM读特定地址NOR读0x9F返回的IDSD卡回CMD0响应这些硬件ID读不对后面全是白费功夫。第四步检查代码层面等待时间够不够、状态寄存器有没有轮询、命令序列有没有按手册来。最后才是查文件系统逻辑FATFS挂载返回什么错误码、是不是空间满了、日志文件长度是否异常。按照这个顺序九成的存储类故障都能在半小时内定位到根因剩下的那一成大概率是硬件批次问题和偶然的电气干扰需要用老化测试去暴露。我做工业控制器多年最大的体会是存储方案不是“芯片能存就算完事”而是一整套可靠性设计。选什么介质、接什么电平、用什么写入策略、怎么处理掉电和磨损环环相扣。你在这上面多花的心思最终都会变成设备更低的返修率和现场更少的半夜电话。这篇存储篇先聊到这里硬件篇·13我准备写通信接口隔离和RS-485总线的那些玄学故障到时候继续。