工业控制器里数据存储经常是最容易被低估的一环。CPU跑不动可以换算法不对可以调但一批配方参数因为掉电丢得干干净净用户是不会给你第二次机会的。“STM32FPGA 分级存储方案”这句话听起来像教科书目录实际做起来却是一张张容量、寿命、时序、掉电行为交织起来的考卷。EEPROM、NOR Flash、SD 卡这三样东西几乎每台设备里都能见到但怎么让它们各司其职、不互相拖后腿才是这篇要聊的重点。我会拿一个实际项目的视角来拆解STM32 负责通信、参数管理和控制逻辑FPGA 负责高速采集和时序处理存储系统则由 EEPROM、NOR Flash、SD 卡分级承担。这篇文章涉及选型思路、接口电路、核心代码、掉电保护和排障经验适合正在做运动控制、边缘网关、测试终端或数据采集器的嵌入式工程师也适合刚接触 STM32 和 FPGA 的爱好者。如果你正准备给自己的控制器加“记忆”这篇可以直接抄作业。1. 先想清楚要存什么再选存储介质1.1 工业控制器的数据不是一种而是三类很多项目把“存储”当成一个需求直接选一个大容量 Flash 从头写到尾结果往往是一边嫌读写慢一边又担心数据被写坏。实际上工业控制器需要持久化的数据至少可以分成三类特点完全不同。第一类是配置参数和标定值比如 PID 系数、温度阈值、设备地址、配方表、零点标定结果。这类数据量小通常只有几百字节到几十 KB修改频率很低但绝不能丢丢了设备等于“失忆”整个工艺都要推倒重来。第二类是固件镜像和 FPGA 配置文件容量从几百 KB 到几十 MB更新不频繁但要求上电加载可靠、升级失败能回滚。第三类是运行日志和采样波形比如故障记录、趋势数据、通信报文、ADC 原始采样数据量最大写入连续虽然单条丢失影响不大但整体不能频繁损坏。这三类数据放在一种介质里要么是小容量介质被海量日志撑爆要么是大容量介质被频繁擦写提前磨损要么是低功耗设计被迫迁就高功耗芯片。所以分级存储不是技术上的炫技而是因为需求天然分成了几层。1.2 三种介质各有各的脾气EEPROM、NOR Flash、SD 卡表面看都是“能存东西的芯片”但内部原理和工作方式差异很大。我做选型时习惯先列一张特性对比表把容量、擦写单位、寿命、接口和典型用途放在一起看。介质典型容量擦写单位写寿命典型接口适合场景EEPROM1KB ~ 1MB字节10万~100万次I2C / SPI参数、配方、标定数据NOR Flash1MB ~ 256MB扇区/块4KB-64KB1万~10万次SPI / QSPI固件、FPGA配置、关键事件SD卡 / NAND8GB ~ 512GB页/块由内部FTL管理依等级3千~10万次SDIO / SPI日志、波形、批量导出EEPROM 最有价值的一点是字节级擦写。你想改一个字节就改一个字节不需要先擦除整块这让参数读写非常灵活。代价是容量做不大、成本偏高所以它只适合放“小而精”的数据。NOR Flash 呢可以支持 XIP 片上执行SoC 可以从它直接启动而且随机读取性能好但写之前必须按扇区擦除不能像 EEPROM 那样直接覆盖。SD 卡内部其实藏着一个小型控制器负责 Flash 翻译层、坏块管理和磨损均衡外人看到的是文件系统接口容量大而且方便但掉电保护能力受卡本身品质影响很大便宜卡一旦掉电一个簇的丢失可能带崩整个文件系统。选型时不要只看标称容量还要看接口、寿命、擦除粒度和掉电行为。比如某块 NOR Flash 标称能擦写 10 万次如果每秒改写一次一天就消耗 86400 次不到两天就报废。所以分级思想必须配上寿命计算。1.3 分级存储的思路其实很简单我习惯把存储系统想象成办公室的资料管理最常用的名片和通讯录放在桌上抽屉里EEPROM重要的合同原件放进保险柜NOR Flash大批量的档案则归档到文件柜SD 卡。每层数据的重要程度、访问频率和容量需求不一样使用的“保管方式”也就不一样。具体到项目里我一般这样分级第一级EEPROM 保存用户参数和配方数据每次修改都做双备份并写校验第二级NOR Flash 保存 Bootloader、应用代码、FPGA 配置文件和关键事件记录采用扇区规划支持升级回滚第三级SD 卡保存运行日志、波形和统计分析数据使用 FatFS 文件系统必要时循环覆盖。这样设计有一个特别大的好处即使 SD 卡彻底损坏或者被人拔出控制器照样能启动参数和固件一个不少即使 NOR Flash 某个扇区写坏了备用扇区可以顶上即使 EEPROM 意外损坏还有一份默认参数备份在 NOR Flash 里。分级不是把数据分开存而是把风险分开扛。2. 硬件架构STM32 和 FPGA 到底怎么分工2.1 存储挂在谁名下取决于数据量很多人问STM32 和 FPGA 都能控制 SPI、I2C、SDIO那存储应该归谁管我的答案是看数据流量和响应实时性。如果采集速率不高每秒只有几十 KB比如温湿度传感器轮询、状态报文记录最简单的方案是把 FPGA 当作前端把数据整理后通过 UART 或 SPI 送到 STM32由 STM32 统一管理 EEPROM、NOR Flash 和 SD 卡。这样代码集中在一个平台FatFS、HAL 库都能直接用排查问题方便。但如果 FPGA 负责的是 ADC 连续采样一秒产生几 MB 数据再往 STM32 里灌CPU 可能大部分时间都在做搬运控制任务会被挤没。这时最好让 FPGA 直接控制存储设备用 FIFO 缓冲后以突发方式写入STM32 只下发命令和读取状态。我做过的运动控制器就属于第二种。FPGA 高速采集编码器和电流信号数据先写入外部 NOR Flash 的环形缓冲区STM32 定期把 NOR 里的数据转移到大容量 SD 卡归档。这样实时采集不受 STM32 负担影响掉电时波形截断的风险也小因为 NOR Flash 的掉电行为比 SD 卡可控得多。2.2 接口选型与电路设计要点确定好谁管哪块存储后电路设计有几个容易踩的坑。EEPROM 用 I2C 接口时SCL 和 SDA 都需要上拉电阻常见阻值是 4.7kΩ。如果总线挂载多个设备或者通信距离稍长可以改成 2.2kΩ但上拉太强会增加功耗、降低扇出。EEPROM 的 WP 写保护引脚最好接一个 GPIO正常运行时拉高防误写需要更新参数时再拉低这对抗干扰很有用。NOR Flash 用 SPI 接口要特别注意 WP# 和 HOLD# 引脚不用时必须接上拉到 VCC否则这两个引脚悬空时受干扰可能莫名其妙进入写保护或保持状态。另外如果 FPGA 和 STM32 共用一根 NOR Flash 的片选线必须保证同一时间只有一个主设备拉低 CS最好用 GPIO 做总线方向切换或直接分时片选。SD 卡建议单独供电因为它在写卡时的峰值电流可以到几十甚至上百毫安和主控共用电源容易造成电压跌落。STM32 的 SDIO 模式需要 CMD、CLK、DAT0-DAT3 根线速度比 SPI 模式快很多但驱动代码复杂一些SPI 模式接线简单兼容性好调试初期可以用如果长期跑建议还是切换到 SDIO。无论哪种模式卡座周围都要加 10μF 和 0.1μF 去耦电容。还要提醒一句现在是 3.3V 的时代EEPROM、NOR Flash、SD 卡基本都是 3.3V 电平。STM32 和 FPGA 的 IO 电压如果也是 3.3V可以直接互联如果板上有 5V 的单片机节点务必加电平转换否则 I2C 总线可能出现闩扣效应严重时直接烧设备。2.3 STM32 与 FPGA 之间的存储协调和掉电信号两块芯片共同管理存储需要一套简单的握手协议。我常用的是请求-应答式STM32 通过一组 GPIO 或 SPI 命令告诉 FPGA“现在开始写波形”FPGA 收到后把存储状态寄存器置为忙写完后置为完成STM32 再读取结果。也可以在共享 RAM 中放一个状态结构体里面包含命令、地址、长度、校验值STM32 和 FPGA 各自原子访问简单可靠。掉电检测是整个存储方案里最容易被低估的部分。不要以为“保存”这件事随时做就行真正出问题的场景十有八九是正在写存储时电源掉了。我习惯在电源入口用电阻分压把电源电压引到 STM32 的 PVD 引脚设置一个比正常电压略低的阈值一旦电源下跌PVD 中断立刻触发。在主电源侧加大容量电解电容比如 1000μF在断掉瞬间还能维持几百微秒到几毫秒的供电。利用这点时间把关键参数和当前状态紧急写入 EEPROM而不是去擦写 NOR Flash因为 NOR 的一个扇区擦除可能要几十毫秒电容撑不住。把“紧急保存”的行为限制在“只写最核心的小数据”是掉电设计的核心原则。3. 关键代码和实操细节3.1 EEPROM 读写最容易翻车的地方用 STM32 HAL 库操作 AT24C256代码本身不长但有几个细节足以让数据“灵异丢失”。第一是页写边界。EEPROM 内部按页组织AT24C256 一页是 64 字节。如果起始地址在页内偏移量较大而你往下一口气写了 64 字节数据会跨到下一页并发生回卷把页首的数据覆盖掉。所以写多字节时每次写入长度不能超过“当前页剩余字节数”。我常用的写法是先用offset start_addr % page_size再算出本次可写长度循环发页写命令。第二是写周期延时和等待。EEPROM 每次写操作后内部要充电完成编程典型时间是 5ms。HAL 的HAL_I2C_Mem_Write只要数据从 I2C 发送出去就会返回不代表数据已经落定。稳妥做法是每次写后延时 5~10ms或者用 ACK 轮询判断内部写周期是否结束。第三是写后校验。不要偷懒跳过这一条尤其是量产产品。写完后立刻读回比较发现不一致就重试重试两次仍失败就切换备份区。// AT24C256 多字节写示例 #define EEPROM_ADDR 0xA0 // 8位设备地址 #define PAGE_SIZE 64 void EEPROM_WriteBytes(uint16_t dev_addr, uint16_t mem_addr, uint8_t *data, uint16_t len) { uint16_t offset; uint16_t to_write; while (len) { offset mem_addr % PAGE_SIZE; to_write PAGE_SIZE - offset; if (to_write len) { to_write len; } if (HAL_I2C_Mem_Write(hi2c1, EEPROM_ADDR, mem_addr, I2C_MEMADD_SIZE_16BIT, data, to_write, 100) ! HAL_OK) { // 重试或记录错误 } HAL_Delay(10); mem_addr to_write; data to_write; len - to_write; } }EEPROM_ADDR应该是包含读写位的 8 位地址如果用户手册给的是 7 位地址 0x50发送时要左移一位成 0xA0。这个细节很多人调半天才发现。3.2 NOR Flash 先擦后写扇区规划是基本功NOR Flash 最大的特点是“写 1 变 0 容易写 0 变 1 难”。所以写前要先擦除把整个扇区恢复成全 1。以 W25Q128 为例它支持 4KB 扇区擦除、32KB 块擦除、64KB 块擦除页面编程一次最多 256 字节。如果项目里有几百字节的参数要更新简单做法是擦掉整个 4KB 扇区再写入消耗的寿命就是整个扇区次数。所以扇区规划比读写函数本身还重要。我习惯在地址最高位划分区域给每个功能模块独立扇区比如 Bootloader 占 64KBApp A 占 512KBApp B 占 512KBFPGA 配置镜像占 1MB参数区占 16KB事件日志区占 4MB。这样 App 升级失败时还能从 App B 启动参数区也可以使用双扇区轮换。关键参数区的轮换策略是用两个扇区交替保存。每次写入时先擦除空闲扇区把新数据写进去并在数据末尾放 CRC 和序列号读取时比较两个扇区的序列号号大的就是新数据。掉了电顶多写坏一个扇区另一个还是完整的控制器上电后自动选择好的那一个。NOR Flash 驱动里等待操作完成是必须有的环节。发完擦除或页编程命令后要不断读状态寄存器的 BUSY 位直到它为 0。如果忽略了这步直接发下一条写命令数据大概率是错的。uint8_t spi_read_status(void) { uint8_t cmd 0x05; // Read Status Register-1 uint8_t status; CS_LOW(); spi_transfer(cmd, 1); status spi_transfer(NULL, 1); CS_HIGH(); return status; } void nor_wait_busy(void) { while (spi_read_status() 0x01); // BUSY bit } void nor_write_page(uint32_t addr, uint8_t *buf, uint16_t len) { uint8_t cmd[4]; nor_write_enable(); cmd[0] 0x02; // Page Program cmd[1] (addr 16) 0xFF; cmd[2] (addr 8) 0xFF; cmd[3] addr 0xFF; CS_LOW(); spi_transfer(cmd, 4); spi_transfer(buf, len); CS_HIGH(); nor_wait_busy(); }如果把 NOR Flash 同时给 FPGA 和 STM32 操作建议定义一个简单的访问仲裁比如用互斥标志双方都开等待超时机制避免一个主设备正在写时另一个发擦除命令。3.3 SD 卡搭配 FatFS但别把写卡当写 U 盘SD 卡容量大读写又方便很多工程师直接套 U 盘的思路打开文件、写入、关闭。但在嵌入式裸机上这套逻辑不能完全照搬。FatFS 挂载后写文件如果只调f_write数据可能还在 FatFS 的内部缓冲区甚至还在 SD 卡内部缓存里。关键数据写完必须立刻调f_sync把文件系统缓存刷到卡里。f_close其实也会做类似同步但频繁开关文件开销太大。我习惯每条日志写完 4KB 缓冲后调一次f_sync异常掉电时最多丢最后一条日志不会丢整个文件系统。还要注意写块对齐。一般 SD 卡的底层扇区是 512 字节FatFS 允许配置为 4096 字节的簇。如果每条日志只有几十字节就写一次会产生写放大长期看磨损严重。我通常把日志攒够 4KB 或按时间批量写既能减少 FAT 更新次数也能提高 SD 卡寿命。FIL fil; UINT br; f_open(fil, 0:/log.txt, FA_WRITE | FA_OPEN_ALWAYS); f_lseek(fil, f_size(fil)); // 追加到文件末尾 f_write(fil, log_buf, len, br); // 写入缓冲 f_sync(fil); // 关键点,把数据刷卡 f_close(fil);为了不写到一半卡满可以建立固定数量的日志文件比如LOG00.CSV到LOG09.CSV按编号循环覆盖。每次挂载后先检查当前最大编号写入超过容量就删最老的文件。这样比在一个文件里无限增长更可控也方便 PC 读取。3.4 FPGA 侧靠状态机和 FIFO 扛住连续写入FPGA 直接控制存储设备时不能用“CPU 式的流程思维”去写代码而是要把操作拆成状态机。比如写一片 NOR Flash状态可能包括发送写使能、发送页编程命令、发送地址和数据、等待 BUSY、判断下一页是否需要继续。每一步都在某个时钟沿跳转配合片选、时钟、数据输出引脚形成一个完整时序。硬件上最重要的是加异步 FIFO。如果 FPGA 以 100MHz 时钟采样数据而存储接口工作在 50MHz两者频率不同数据必须先用 FIFO 缓冲跨时钟域。FIFO 深度要根据突发流量来算假设采样速度 2MB/s目标设备平均写入速度 600KB/s如果持续写入 1 秒FIFO 至少有 (2-0.6)MB 也就是约 1.4MB这在 FPGA 内部 RAM 里可能放不下需要外部 SRAM 或 DDR。所以工程上不能只看峰值速度要把“擦除时间、命令开销、等待时间”都算进平均写入速度里。如果只是控制 I2C EEPROMFPGA 侧也可以用状态机实现读写操作网上有不少代码参考。我的建议是先用 testbench 做仿真不要直接上板。写一个简单的 I2C 主状态机仿真时抓地址、数据、ACK 和 STOP 时序确认满足 EEPROM 手册要求后再接真实芯片。FPGA 排错成本高仿真这一步能省掉大量示波器时间。4. 问题排查与避坑实录4.1 数据丢失几乎都出在掉电瞬间我遇到过最经典的问题客户前一天设好一批参数第二天上电全部回到出厂值。查了一圈EEPROM 没坏代码写入流程也没错唯一的异常是设备关机时恰好在写参数写了一半电源就没了旧数据被破坏新数据没写完版本标识又恰好指向了损坏区。解决这种问题的标准动作是三步。第一步增加掉电检测利用 PVD 中断在电压下跌瞬间进入紧急保存流程第二步把“正在写”标志和版本号独立存放只有写成功后才更新版本号第三步EEPROM 做双区轮换写新数据先写到备用区校验通过后再切换活动区。这套机制看起来增加了很多细节但能把“掉电写坏”的概率从高概率事件降到几乎不可能。另一个容易犯的错误是“保存太频繁”。参数显示值一旦变动就立刻写 EEPROM会迅速消耗寿命。我见过一位客户因为温度实时显示值用了防抖不彻底EEPROM 不到三个月就挂了。必须在参数确认或超过一定时间无变化后才写减少写次数比选更贵的芯片更有效。4.2 读写失败先从总线时序查起I2C 偶尔 NACK、SPI 读出来全是 0xFF、SD 卡挂载超时这类问题大多不是芯片坏了而是时序和电平问题。I2C 总线上拉电阻选得太大会导致上升沿太慢通信速率提不上去选得太小会增大漏电流。400kHz 快速模式一般推荐 1.5k~4.7kΩ具体根据总线电容调。SPI NOR Flash 要特别注意 CPOL/CPHA。W25Q 系列通常支持 Mode 0 和 Mode 3但如果驱动用了不匹配的模式读 ID 和状态寄存器会全错。最简单的方式是先读 JEDEC ID读到 0xEF 才是 W25Q 系列读不到就先翻 SPI 极性和相位。SD 卡初始化也有时序要求上电后要等至少 74 个时钟周期再发 CMD0然后等待卡进入 SPI 模式。如果初始化总是超时多半是卡的供电不足或者 DAT/CMD 上拉没做。还有一个经验是“一次只改动一个变量”排查问题时把 SDIO 改成 SPI 模式先跑通再用 SDIO 模式替换这样能快速隔离是卡问题还是接口问题。4.3 寿命问题算清楚再定策略很多人以为选了工业级芯片就万事大吉实际上寿命和你的写入策略直接相关。举个例子EEPROM 标准寿命 100 万次如果每 10 秒写一个计数大概 116 天就写完所有寿命。所以参数写入必须节流。NOR Flash 的擦写次数是扇区级别衡量的。如果一个 4KB 扇区只用来存 128 字节的关键事件每擦一次整个扇区的寿命就少一次。解决方式是“磨平”磨损把事件记录区拆成多个小扇区写满一个再换下一个同时记录每个扇区的写计数定期把数据搬到写次数少的扇区。简单轮换就能让寿命翻几十倍。SD 卡的寿命相对隐蔽因为内部 FTL 会做磨损均衡但你无法从外部完全控制。工业级 SD 卡在随机小写场景下的写放大因子可能接近 10普通卡更严重。如果一天写入量 4GB标称 32GB 的普通卡用不了几年。所以对长期高频记录我建议优先选工业级高寿命卡并把写入频率降下来数据先聚合再写盘。5. 一个完整实例运动控制器上的分级存储5.1 系统划分和上电流程我做过一台小型运动控制器主控是 STM32F405搭配一片 Artix-7 FPGA。控制器的需求是保存 100 组工艺配方、支持固件 OTA 升级、记录 10 通道电流采样波形故障触发时保存触发前 2 秒的高频数据。这个需求刚好把三种介质都用上了。EEPROM 选用 AT24C256存储 100 组配方、设备 ID 和标定数据。每组配方 256 字节加上索引约 30KB剩余空间放设备生命周期信息。NOR Flash 选用 W25Q128分成 Bootloader、App A、App B、FPGA 配置镜像和关键参数区App 和 FPGA 镜像双份存放出现升级失败还能回滚。SD 卡选 32GB 工业卡保存运行日志和归档波形。FPGA 采集的电流波形数据并不直接写 SD 卡而是先写 NOR Flash 的高速环形缓冲区。正常运行时FPGA 把最新一秒钟的波形写入环形区STM32 每秒把这一秒的旧数据读出来转存到 SD 卡故障触发时FPGA 把触发前 2 秒的数据搬到 NOR Flash 的保留区并通知 STM32STM32 将“有未归档故障记录”的标志写到 EEPROM。上电后 STM32 先读 EEPROM 参数加载 FPGA 配置再检查标志如果有待归档记录就把它搬到 SD 卡搬完后清标志。这样即使掉电最关键的高频数据在 NOR 里留着日志类数据在 SD 卡里参数永远有个可靠副本。这个架构还有一个好处SD 卡文件系统如果损坏控制器照样能正常工作。只有运行日志缺失参数和固件都完好现场维护时可以拔卡重新格式化不影响生产。5.2 后续还能怎么扩展如果你正在考虑更低成本或更大容量的方案可以站在这个分级模型上继续扩展。一个是把 NOR Flash 换成带磨损均衡的掉电安全文件系统比如 LittleFS。自己写扇区轮换始终容易遗漏边界情况LittleFS 内置掉电恢复和磨损均衡用在参数区和事件记录区非常合适只是代码量和 RAM 开销会大一些。另一个是如果数据量很大FPGA 直写 SD 卡是一条路但驱动和文件系统实现成本高建议优先考虑 FPGA 把数据交给 ARM 侧用 Linux 的文件系统处理很多边缘网关就是这么做的。最后再分享一段我自己的体会做硬件和底层驱动这十几年存储方案最忌讳“拍脑袋选型”。每一种芯片都有它的边界EEPROM 胜在字节级灵活NOR Flash 胜在读取可靠和启动友好SD 卡胜在容量和通用性。先在纸上把数据分成参数、代码、日志三类再画一个掉电时序图最后才打开原理图选芯片这会比先买开发板再回头补方案顺利得多。样机阶段还有一个必做测试连续写入十分钟然后在随机时间点直接拔电重复几十次。能扛过这一关的存储方案才有资格往现场放。