工业控制器分级存储方案：EEPROM、NOR Flash与SD卡分工实践

做工业控制器这些年最让我头疼的不是算法不是通信而是“数据到底存在哪儿”。设备要保存的参数、固件、FPGA 配置文件、运行日志、历史曲线数据性质完全不同——有的几天才改一次有的每秒都在写有的丢了会出安全事故。单一存储介质根本扛不住所以在我设计的 STM32FPGA 架构里存储是分级的EEPROM、NOR Flash、SD 卡各管一段这也成了硬件篇系列里被问得最多的话题。这篇就来把这套分级存储方案的原理、电路、写入策略和踩坑过程完整讲一遍适合做工业控制器、边缘网关、数据采集终端和运动控制器的工程师参考。1. 为什么工业控制器必须做分级存储1.1 工业数据不是一种是三种很多刚入行的工程师容易把“数据存储”理解成“往 Flash 里写个数组”等到设备在现场跑几个月问题就像雪崩一样冒出来。控制器的数据可以粗暴分成三类第一类是配置参数和标定数据。比如设备编号、IP 地址、报警阈值、PID 参数、模拟量校准系数。这类数据的特点是容量特别小几 KB 以内、写入次数极少一天可能就写几次但要求掉电后立刻能读出来而且不能出现半个字节损坏。第二类是程序和 FPGA 配置文件。STM32 的固件、FPGA 的比特流都属于必须上电就能快速加载的文件。它们对随机读性能要求高写入频率极低通常几个月才升级一次但容量比参数大一个量级固件几百 KB 到几 MB 很常见。第三类是运行日志和历史数据。这是最让人头疼的部分。温度曲线、故障事件、通信报文、统计数据写入可能从每秒几次到每分钟一次不等容量需求随运行时间线性增长几百 MB 甚至几 GB 都有可能而且这类数据丢失一部分通常不会致命但绝对不能把整块 Flash 写穿。这三个需求放在一起你会发现不存在一种介质能同时满足“字节级可靠改写”“随机快速读取”“大容量频繁写入”这三个条件。于是分级存储几乎是工业控制器的主流解法而不是什么高级技巧。1.2 单介质方案的崩溃现场我见过不少项目只靠一片 MCU 内部 Flash 存所有东西结果固件升级一次参数区被连带擦掉也见过有人为了图省事把日志直接怼进 EEPROM一个月的设备就出现读写错误。单一介质的问题不是“容量不够”那么简单。只用 EEPROM 的话一片大容量的 I2C EEPROM 也就 1 Mbit实际能用的用户字节不过 128 KB存不了历史曲线而且 EEPROM 按字节擦写虽然寿命有好几十万次但频繁写日志一样会提前报废。只用 NOR Flash 的话大容量的并行 NOR 非常贵串行 QSPI NOR 虽然便宜但擦除最小单位是一个扇区通常 4 KB要改 16 字节数据得先把整扇区读到 RAM、修改、擦掉、再写回去过程复杂不说如果中途掉电整个扇区可能报废。只用 SD 卡的话启动过程依赖卡能不能被正常识别工业现场振动、电压跌落、异常拔卡都会让 SD 卡出现意想不到的问题。我后面会专门讲一个 SD 卡内部寄存器锁死的案例那是纯硬件文档里找不到的经验。所以我的方案是EEPROM 管参数、NOR Flash 管程序和关键日志、SD 卡管大数据历史。三者配合各自干自己最擅长的事。2. 三种存储介质的原理与边界2.1 EEPROM能改字节的便签本EEPROM 的存储单元本质上是浮栅晶体管靠控制栅极和浮栅之间的电荷隧穿来改变阈值电压。它的最大特点是可以按字节擦写写一个字节和写一整页成本差别不大。这非常适合“每次只改一个参数”的场景。工业上常用的 I2C EEPROM比如 AT24C02、AT24C256、CAT24M01容量从 2 Kbit 到 8 Mbit 不等。选型时除了看容量还要盯住三个参数写周期时间 tWR典型值 5 ms意思是发完一页数据后芯片内部需要 5 ms 才能真正完成编程。这个时间不能省否则下一个写指令会被忽略。页大小AT24C256 的页大小是 64 字节AT24M01 可以达到 256 字节。一次连续写操作不能跨页否则地址回卷会把你写的下一段数据覆盖到本页开头。工作温度范围工业级要选 -40°C 到 85°C如果是车规还要看 AEC-Q100 认证。很多人以为 EEPROM 写坏是因为寿命不够其实大多数情况是死在“跨页写”和“写周期等待不够”这两个细节上。我习惯在写完每一页后读回校验一下读到的内容对不上就重写最多重试三次这比事后通过各种骚操作找回参数靠谱得多。2.2 NOR Flash能随机读的程序管家NOR Flash 的浮栅结构决定了它的读操作可以按字节随机访问所以支持 XIP直接在 Flash 上执行代码。它不像 NAND 那样需要坏块管理、ECC 和页映射非常适合存固件和 FPGA 配置。串行 NOR Flash 比如 W25Q64JV、W25Q128JV 是现在最常用的选择接口从普通的 SPI 升级到 QSPI四线读速度可以轻松跑到几十 MB/s。QSPI 模式下CLK 频率到 100 MHz 都很常见STM32 的 QSPI 外设可以直接驱动FPGA 也可以用软核或者硬核控制它。NOR Flash 的寿命单位是“块擦除次数”通常标称 10 万次。这不意味着你只能擦 10 万次而是说在数据保持能力、写错误率等指标满足规格书的条件下最多擦 10 万次。如果做日志存储一定要注意磨损均衡不要让同一块扇区反复被擦否则其他扇区还很健康这一块先挂了。另外还有一个容易被忽略的问题双 Bank 结构。很多大容量 NOR Flash 内部被分成两个 Bank如果代码在 Bank A 执行同时去擦写 Bank B通常没问题但如果你擦写的是 Bank A 的某个扇区而那里面有正在执行的代码Flash 会直接报 Busy极端情况下 CPU 取指失败直接死机。所以设计程序升级和日志分区时必须提前规划好哪些扇区放 Bootloader、哪些放 App、哪些放 FPGA 配置、哪些放只写日志。2.3 SD 卡大仓库但不是保险箱SD 卡内部其实就是一片 NAND Flash 加上一颗主控芯片。主控负责坏块管理、ECC 纠错和磨损均衡对使用者来说是一个“黑盒”。这既是优点也是缺点优点是你不必关心 NAND 的底层细节缺点是你无法确定主控在掉电瞬间到底在做什么。工业控制器里用 SD 卡最关键的是选“工业级”卡。普通消费级卡用 TLC/QLC 颗粒写寿命写满一块可能只有几百次在频繁写日志的场景下几个月就可能出现坏块率飙升、写入变慢甚至掉卡。工业级 SD 卡大多采用 SLC 或者 pSLC 颗粒寿命和温度范围都更靠谱。接口上SD 卡支持 SDIO 和 SPI 两种模式。SDIO 模式有 4 根数据线速度快SPI 模式只需要 4 根线布线简单速度慢一些但对大多数日志应用足够。STM32 的 SDMMC 外设跑 SDIO 模式Linux 和复杂嵌入式系统用得最多裸机或者 RTOS 下我建议用 SPI 模式初始化简单调试也更直观。SD 卡还有一个特点它不是一个纯存储芯片而是一个带协议的状态机。上电后需要主机发送一串初始化命令经过 CMD0、CMD1、ACMD41 等步骤才能进入数据传输状态。如果初始化时序不对或者供电电压抖动卡可能进入一个“半死”状态这就是后面要说的坑。三种介质放一起对比会更清楚项目EEPROMNOR FlashSD 卡典型容量2 Kbit ~ 8 Mbit1 MB ~ 128 MB几百 MB ~ 几十 GB最小擦写单位字节/页扇区4 KB 常见内部由主控管理写寿命100 万次左右10 万次擦除消费级几千次工业级更高读速度慢I2C 400 kHz快支持 XIP/QSPISDIO 快SPI 慢掉电保护较弱断电瞬间写坏扇区擦除时掉电危险依靠主控仍需注意典型用途参数和配置固件、FPGA 配置、日志历史数据、文件包3. STM32FPGA 怎么分工才合理3.1 一块板子上的三条存储通道STM32 和 FPGA 同时存在存储设计就不能只考虑“哪颗芯片挂在哪条总线上”。我把整个存储系统按访问主体拆成三条通道通道一STM32 直接管理 EEPROM。参数区数据量小但必须保证强一致性和写保护策略。STM32 用 I2C 访问 EEPROM软件上做页写、读回校验和写保护切换。FPGA 不参与这部分的访问避免两个主机抢 I2C 总线。通道二STM32 通过 QSPI 管理 NOR Flash。NOR Flash 同时承担三个职责放 STM32 固件、放 FPGA 配置文件、存循环日志。固件区由 Bootloader 负责FPGA 配置文件由 STM32 在启动时读出来发给 FPGA或者系统支持从 SPI NOR 直接配置 FPGA。日志区则用环形缓冲算法让 STM32 定期写入。通道三STM32 通过 SDMMC/SPI 管理 SD 卡。SD 卡存的是大块历史数据和升级包。FPGA 采集的数据会先经过内部 FIFO 暂存再由 STM32 用 DMA 搬运到 SD 卡。这样 FPGA 不需要自己去实现 FAT32 文件系统省去很多麻烦。为什么不让 FPGA 直接写 SD 卡因为 SD 卡文件系统要处理目录、FAT 表、损坏恢复等逻辑用 FPGA 硬逻辑实现太痛苦就算用软核也绕不开运行一个软件栈。STM32 有现成的 SDMMC 外设和 FatFs 库让 STM32 做“存储管理员”FPGA 做“数据搬运工”才是发挥各自优势的架构。3.2 我常用的存储分区表在我的实际项目里EEPROM 通常只放最关键的小参数包括设备序列号、MAC 地址、模拟量校准系数、报警阈值、上次关机标志位。一片 AT24C256 就够地址线全接地只保留 WP 控制引脚。NOR Flash 则规划成四个区分区起始地址大小内容Bootloader0x0000000064 KBSTM32 启动程序App0x00010000768 KB用户程序FPGA Config0x001000002 MBFPGA 配置位流Log Ring0x003000002 MB循环日志这样做有两点好处一是 App 升级时可以从 Bootloader 直接擦写 App 区不影响日志区二是 FPGA 配置位流和固件分开FPGA 升级不用动 STM32 程序。如果把 FPGA 配置文件放在 App 分区里每次改 FPGA 逻辑都导致整包升级出问题不好定位。SD 卡则只用来存三种内容历史趋势数据文件按天生成 CSV 或二进制文件、故障事件抓拍时间戳加原始报文、升级包暂存区。升级包一般是用户通过网口或者 USB 拷到 SD 卡然后 STM32 再去解析升级。3.3 FPGA 侧的缓冲与时序接口FPGA 在存储链路里的角色经常被低估。控制器采集的数据往往是突发性的——比如电机启动瞬间电流采样率飙到 100 kSPS持续几百毫秒数据量可能几十 KB。如果让 STM32 中断实时响应每个采样点CPU 会被拖垮让 FPGA 把所有原始数据直接写 SD 卡也不现实。我通常的做法是在 FPGA 里用双口 RAM 或 FIFO 做缓冲。数据进来后FPGA 打成带帧头、长度、时间戳的帧写进 FIFOSTM32 用 DMA 周期性读取 FIFO再决定写 NOR Flash 还是 SD 卡。这样 CPU 的开销只是“读 FIFO 写卡”而不是“打断每个采样点”。FPGA 侧接口逻辑本身也需要细致仿真。拿 I2C 读写 EEPROM 来说如果 FPGA 侧有时钟域转换高位的 START、STOP、ACK 时序很容易出问题。我每次写这类接口都会先用一个简单的 Testbench 做仿真把 SDA/SCL 波形拉出来看是否符合 I2C 时序要求。同样的还有 UART_RX、SPI ADC、LVDS 接收这类高速接口不先仿真就上板调试一旦出问题很难分清是逻辑问题还是硬件问题。4. 存储接口电路设计容易翻车的细节点4.1 I2C EEPROM上拉电阻和写保护别乱来I2C 是开漏总线必须外部上拉。上拉电阻阻值取决于总线电容和通信速率。工业环境板子上器件多总线电容常常不小400 kHz 模式下我一般用 2.2 kΩ 到 3.3 kΩ100 kHz 可以用 4.7 kΩ 到 10 kΩ。阻值选太大边沿过慢数据出错选太小灌电流大功耗增加。这个不是玄学用示波器量 SCL/SDA 上升沿超过 datasheet 要求的最大上升时间就得换小电阻。EEPROM 的写保护引脚 WP 非常关键。很多参考设计让 WP 直接接地图省事但这样固件运行时如果发生意外的 I2C 写操作参数区就可能被改写。我建议把 WP 接到 STM32 的一个 GPIO常态下拉为低允许正常写只有固件升级或者参数校准流程里才拉高禁止写。这样即使程序跑飞I2C 意外发出写命令EEPROM 也会由于 WP 拉高而拒绝写入。注意 GPIO 在 MCU 复位期间的状态也要考虑最好在 WP 脚上加一个下拉电阻保证芯片默认不写。4.2 QSPI NOR Flash四线模式惹的祸串行 NOR Flash 用 QSPI 四线模式时IO2 和 IO3 就不再是单纯的 WP 和 HOLD 引脚了。很多人画板子时直接照抄 datasheet 里的引脚说明结果发现 IO2/IO3 上挂了其他外设或者 HOLD 引脚被拉低导致 Flash 在工作时冻结。正确做法是IO0~IO3 都连接到 MCU 的 QSPI 引脚不要在中间串大电阻也不要随便接上拉下拉。尤其 HOLDIO3引脚在四线模式下是数据线如果硬件上拉把它固定在高电平还好但如果接了下拉Flash 在通讯时可能不断被 HOLD 打断。此外NOR Flash 的片选 CS 必须由主机控制不能接死。CS 拉低表示一次传输开始拉高表示停止。如果 CS 被硬接低电平Flash 会把每次时钟边沿都当成有效数据读出来的 ID 乱七八糟这问题我见过不止一次。对于 FPGA 也使用同一片 NOR Flash 的场景要注意两条访问路径的分时。比如 STM32 通过 QSPI 读 FPGA 配置文件或者 FPGA 上电后直接通过 SPI 从 Flash 加载自身配置这两个流程不能同时发生。硬件上可以用一个总线交换芯片或者软件上约定状态机STM32 先握有 Flash完成 FPGA 配置后释放总线FPGA 后续不再访问该 Flash。大多数情况下我更推荐 FPGA 配置文件和 STM32 固件分开放在两个 Flash 里虽然成本高一点点但省去仲裁逻辑排查问题也轻松很多。4.3 SD 卡接口电压、上拉和 ESD 一个都不能少SD 卡接口设计有三个高频坑。第一个坑是电压域。SD 卡有 3.3V 和 1.8V 两种信号电平如果 MCU 是 3.3V IO就配置为 3.3V 工作模式。如果用了电平转换芯片必须注意方向控制和与其他总线的隔离。SD 卡的 VDD 引脚和 IO 引脚最好分别加滤波电容和磁珠避免电机启停造成的电压波动影响卡内部主控。第二个坑是上拉电阻。SDIO 模式下的 CMD 线、DAT0~DAT3 都需要上拉一般 10 kΩ 到 47 kΩ。DAT1 和 DAT2 尤其要注意因为卡检测寄存器会用到它们。有些 STM32 的 SDMMC 外设内置上拉但裸机程序里可能配置不对建议在硬件上明确加上拉软件上只管控制时钟频率。第三个坑是 ESD 和热插拔。SD 卡座是外露接口容易被静电打坏。我在数据线和电源线上都加了 TVS 管同时把卡座的金属外壳直接接机壳地。热插拔场景下先保证电源稳定再允许卡初始化硬件上可以通过卡检测开关 CD 来触发“允许初始化”信号软件上检测到 CD 变化后延时 50 ms 再做上电序列。这些细节看起来琐碎但现场故障往往就出在某个引脚拉没拉对上。PCB 布线时SDIO 的四条数据线尽量等长时钟线 CLK 要短而直不要走太长过孔如果板上有 FPGA 高速信号传输线间的串扰也会体现在 SD 卡读写出错上。5. 分级写入策略与掉电保护实现5.1 写入节奏哪些数据走哪条路硬件电路定了软件写入策略才是真正体现这套方案价值的地方。我给自己定了一套简单的数据流规则配置参数变化后立即写 EEPROM。比如用户在前面板改了一个报警阈值操作结束后马上开一个存储任务把整个参数结构体按页拆开写入写完读回校验。不做延迟合并因为参数如果丢了设备可能按错误阈值运行这是安全隐患。关键运行日志定时批量写 NOR Flash。我用一个循环日志块。STM32 维护一个内存缓冲区每写满 512 字节才触发一次 NOR Flash 扇区写入。这样一天即使产生大量日志NOR Flash 的擦写次数也能保持在很低水平。历史数据和事件抓拍按文件写 SD 卡。数据积累到一定程度或者到了固定的时间边界才打开一个新的文件写入。SD 卡文件操作不能太频繁否则文件系统碎片和目录项更新会变成新的瓶颈。我还会把“数据优先级”和“存储介质”做成一张表写代码时严格按照这张表执行。比如掉电瞬间所有总线访问必须按优先级抢占第一步保护 EEPROM 参数区第二步保护 NOR Flash 日志区第三步才尝试把缓冲区的数据刷到 SD 卡。如果优先级反了掉电瞬间 SD 卡还没写完参数反而被丢那就得不偿失。5.2 掉电保护的“三道防线”掉电保护不是简单地在电源上加个大电容。好的工业控制器会做三级防护。第一级是电源监测。STM32 和 FPGA 都要有一个电压监测引脚当 5V 或 3.3V 跌落到阈值以下时触发掉电中断。这个中断的优先级必须设成最高里面只做一件事把当前正在进行的存储操作状态标记下来然后快速切换 EEPROM 的 WP 脚为高阻或高电平禁止意外写入。第二级是后备储能。在掉电中断被触发后系统通常还有几毫秒到几十毫秒的时间继续工作。这取决于电源输入端的设计。常用的做法是给核心电源轨并联一个几百微法的电解电容或者超级电容保证在这段时间内 MCU 和存储器还能正常读写。如果掉电流程里要写一页 NOR Flash那至少需要预留几十毫秒这个时间要在硬件设计时就计算好。第三级是存储协议的掉电安全设计。NOR Flash 日志区最好用双备份方案两个扇区交替写每次先写新扇区、标记状态再擦旧扇区。这样即使在擦除旧扇区时掉电日志仍然可以从新扇区恢复。SD 卡文件系统则依赖 FatFs 的 f_sync 机制每次写完一个数据块后立即同步 FAT 表不能一直依靠 f_write 的缓存否则掉电后 FAT 表是最旧的那份文件长度和内容对不上。5.3 寿命计算你的设计能跑多久很多人的设计只考虑了“容量够不够”没考虑“寿命扛不扛得住”。这里给一个简单的计算思路。EEPROM 寿命标称典型 100 万次擦写。假设一个参数每天被修改 10 次一个月 300 次一年 3650 次。100 万次除以每年 3650 次大约能用 273 年。所以 EEPROM 存参数几乎不用担心寿命除非你的设备疯狂地每秒都在写参数那就不是正常操作。NOR Flash 寿命假设用 2 MB 做日志环形区扇区大小 4 KB一共有 512 个扇区。如果每天产生 50 KB 日志那么大约 4 天才写满 2 MB磨损均衡后平均每个扇区每月擦个几次。10 万次擦除寿命意味着这种日志方案可以跑几十年。前提是日志量不会突然爆发如果一天产生 2 MB 日志每天都把整块区域擦一遍那 10 万天大约是 274 年依然够用。真正要警惕的是把日志累积到几天才清理一次清理时一次性擦几千个扇区那样磨损反而不均匀。SD 卡寿命工业级大卡一般不会因为正常写入量在短时间内挂掉但消费级卡问题就比较明显。我做过一次压力测试一块普通 TLC 高速卡持续以 1 MB/s 写入用了三个多月后开始掉速、掉卡对应的累积写入量大约几个 TB。所以如果项目要长期写数据SD 卡一定要按写入量来选算一下一天写多少 GB、卡片能够承受多少 TBW再决定换不换卡。6. 实测踩坑记录SD 卡锁死与 Flash 写坏6.1 SD 卡内部寄存器锁死现象、定位与恢复先讲一个最有代表性的现场故障。设备正常运行时STM32 通过 SDIO 读取 SD 卡里的历史数据突然读取超时然后卡就“消失了”。把卡拔下来插到读卡器里Windows 能识别但插回设备系统死活初始化失败。示波器看 CMD 线发现 STM32 反复发 CMD0卡就是不给响应和“失踪”了一样。后来查下来这是 SD 卡主控内部状态机锁死了触发原因是系统掉电瞬间正好在写卡或者时钟信号上出现毛刺。SD 卡要求上电后有一个稳定的时钟窗口才能初始化如果初始化时电源不稳主控可能进入异常状态必须重新上电或者执行特殊的复位序列才能恢复。处理的顺序一般是这样先把 SD 卡从系统中断开等所有电源轨稳定。拉高 CS/DAT3给 CLK 连续发 74 个脉冲作为上电同步序列。发送 CMD0 进入 SPI 模式或者根据当前接口模式发送对应复位命令。如果仍然无响应尝试发送 CMD1MMC 模式或 ACMD41SD 模式并检查返回的错误标志。最无奈的办法是重新掉电再上电并且换一套初始化时序。这个案例最大的教训是别在掉电瞬间访问 SD 卡。我的硬件设计后来把 SD 卡的写操作几乎都安排在掉电状态下仅执行“关闭文件、同步缓存”绝不在掉电瞬间往卡里写大块数据。宁可损失最后几十 KB 数据也不能让卡反复锁死。6.2 FATFS 掉电损坏比卡锁死更隐蔽的坑另一个我踩了很多次的坑是 FATFS 文件系统在掉电后损坏。现象是设备重新启动后 SD 卡挂载失败读卡器打开一看目录全是乱码或者文件大小变成负数。这个问题比 SD 卡锁死更隐蔽因为它不是每次掉电都发生而是随机复现很容易被误判为卡质量问题。核心原因是 FATFS 的文件分配表FAT 表和目录项更新不是原子的。写一个文件需要修改文件数据区、FAT 表、目录项三个位置如果掉电发生在某一环FAT 表和实际数据就不一致了。解决思路有三层第一层是写文件时使用“临时文件 重命名”策略。先写一个data.tmp写完后同步关闭再把它重命名为data.csv。因为这个流程中只存在两个文件名不存在旧文件被破坏的问题。第二层是定期执行f_sync特别是在文件写入末尾和掉电中断里。很多工程师把f_write当成“已经写盘”其实数据还留在 FatFs 的库缓冲区里如果掉电缓冲区内容直接丢失。第三层是给 SD 卡做镜像备份。量产时我会先用dd或 Win32DiskImager 把一张格式化好的 SD 卡做成镜像再镜像到其他卡。这样即使卡在运行中被写废也能通过恢复镜像回到出厂状态不用在设备上重新建文件系统。镜像命令很简单sudo dd if/dev/sdb of./industrial_sd_backup.img bs4M statusprogress恢复时反过来sudo dd if./industrial_sd_backup.img of/dev/sdb bs4M statusprogress做镜像前注意把卡卸载干净否则复制出来的 FAT 表可能是不干净的。6.3 NOR Flash 与 EEPROM 的写保护实战NOR Flash 擦写期间掉电最容易出现“扇区半擦除”问题。我在测试时发现擦写过程中如果 STM32 发生看门狗复位复位的代码会立刻重新执行但 Flash 还停留在擦除状态此时读取出来的内容可能是全 0xFF 或者乱码。轻则日志丢失重则把 Bootloader 所在扇区搞坏设备变砖。解决办法是给 Flash 擦写流程加“段保护”也就是在擦写之前先把目标扇区的内容备份到另一个扇区写完后再做 CRC 校验。同时把擦写操作放到临界区禁止一切中断和看门狗喂狗直到操作完成。这在工业设备上不是夸张因为一次完整的扇区擦写加写回大约耗时几十毫秒到几百毫秒短时间阻塞 CPU 是值得的。EEPROM 的写保护也有一个容易被忽略的细节STM32 复位瞬间 GPIO 会变成高阻这时候如果 WP 引脚悬空EEPROM 的写保护是不确定的。我前面说 WP 接 GPIO 并加下拉就是为了保证复位瞬间 WP 是确定低电平允许写还是确定高电平禁止写要看你希望设备在异常状态下是“允许校准”还是“禁止篡改”。我一般选复位瞬间默认高电平禁止写直到程序明确初始化并把 WP 拉低。这个方向不能搞反。另外在 I2C 写 EEPROM 时如果程序使用 DMA 发送数据一定要在 DMA 传输完成后等待 EEPROM 的 ACK 和内部写周期结束。很多“EEPROM 数据随机丢”的案例就是 DMA 设置了缓冲大小但页面大小没对齐跨页覆盖了上一个页的数据。写之前先算好当前地址在页内的偏移剩余空间不足就拆成两笔写。uint8_t page_size 64; /* AT24C256 */ uint16_t addr 0x1234; uint16_t offset addr % page_size; uint16_t remain_in_page page_size - offset; uint8_t len (data_len remain_in_page) ? data_len : remain_in_page; /* 第一笔写 addr 开始 len 字节 */ /* 第二笔写 addrlen 开始 data_len-len 字节 */这套分级存储方案我从最早的“一板走天下”到现在已经改了三版。越往后越发现存储设计不是硬件工程师单独能拍板的它和固件架构、FPGA 逻辑、现场运行工况全都绑在一起。EEPROM、NOR Flash、SD 卡三者的分工表面上是硬件的取舍实际上是对整个控制器“哪些数据不能丢、哪些数据可以丢、哪些数据应该放哪”的系统思考。每次现场出存储问题我最先查的不是芯片型号而是当初定下的写入规则是否被某行代码悄悄破坏了。