文章目录摘要为什么不用外挂 EEPROM前置准备架构总览Flash 的两个硬约束设计决策页轮换 vs 原地擦写 vs 外挂 EEPROMCubeMX 与地址规划核心代码页轮换驱动记录结构查找最新记录写入追加 轮换页轮换磨损均衡核心掉电一致性验证性能实测理论 vs 实测对照故障排查问题一写 Flash 返回 HAL_ERROR数据写不进去问题二写进去的数据读出来错位/丢字节问题三断电后读回的数据是旧的最新写入丢失问题四程序升级后 Flash 内容被破坏或 EEPROM 区失效总结摘要STM32F103 系列芯片没有集成 EEPROM但很多产品又需要掉电保存校准参数、用户配置和运行日志这类小数据。本文基于 STM32F103C8T6 的 64KB 内部 Flash用 HAL 库实现一套带磨损均衡的Flash 模拟 EEPROM模块通过页轮换算法把 4 个 1KB 页组织成虚拟存储空间配合头部元数据管理有效记录。实测单次写 64 字节耗时约 3.2ms、读耗时约 1.1μs连续 10 万次写入无坏页、上电回读数据 100% 一致把擦写寿命从单页固定的 1 万次提升到理论上 4 万次。文末附完整驱动代码、擦写时序实测数据以及写保护、半字写入、页错位三类高频故障的排查过程。为什么不用外挂 EEPROM做带配置功能的产品时最常见的需求就是设置项掉电不丢。摆在面前的方案有两条外挂 24C02 这类 I2C EEPROM字节级可擦写、寿命 100 万次但要多一颗芯片、多两根线、多写一套 I2C 驱动。用内部 Flash 模拟 EEPROM零硬件成本但 Flash 只能整页擦除 半字写入寿命只有 1 万次左右操作逻辑复杂得多。多数量产项目里硬件空间紧张、成本敏感会优先考虑方案二。但直接用擦除整页再写的粗暴做法有个致命问题如果每改一个字节就擦一次整页1 万次擦写寿命很快就耗尽。所以这篇文章的核心不是教你调用HAL_FLASH_Program而是教你搭一套页轮换 元数据管理的磨损均衡机制把寿命摊到多个页上。本文目标读完你能拿到一个可直接移植的Flash_EEPROM模块支持任意结构体的掉电保存并且理解它为什么比裸擦写活得久。完整工程代码与测试脚本可在 CSDN 下载频道 获取VIP 免费。前置准备硬件STM32F103C8T6 最小系统板、ST-Link V2软件STM32CubeMX 6.9.1、Keil MDK 5.38、STM32Cube FW_F1 V1.8.5参考手册《RM0008》第 2.3 节Flash 模块和第 3 章Flash 编程架构总览先建立整体认识。Flash 模拟 EEPROM 的难点在于擦除粒度 ≠ 写入粒度Flash 只能按 1KB 页擦除却能按 16bit 半字写入。下面是这套模块的存储布局写入流程否是写满当前页?追加新记录迁移有效记录到新页擦除旧页记录结构2字节 魔数 0xA5A52字节 变量ID2字节 数据长度N字节 数据内部Flash 64KB活动页页0 0x0800F000记录1 头数据记录2 头数据空闲区 0xFF...页1 0x0800F400页2/页3 备用页核心思想一句话概括永远只往活动页追加写不原地改写写满一页就把最新的有效数据搬到下一页再擦掉旧页。这样每页的擦除次数就被分摊了。Flash 的两个硬约束写代码前必须把这两条物理特性刻进脑子里否则后面所有坑都源于此只能从 1 写 0不能从 0 写 1Flash 编程只能把某位从 1 置 0想把 0 改回 1 必须整页擦除。所以原地改一个字节在 Flash 上根本做不到擦除后整页全是0xFF。写入粒度是半字16bitSTM32F103 的 Flash 只能按 16bit 编程不能按字节写。所以一个 8bit 的数据也要凑成 16bit 再写。这两条决定了我们的存储结构必须追加式 半字对齐。下面讲实现时会反复用到。设计决策页轮换 vs 原地擦写 vs 外挂 EEPROM对比维度原地擦写每改一擦页轮换本文外挂 24C02硬件成本00芯片布线单页寿命1 万次1 万次 × 页数100 万次写耗时~20ms擦写~3ms仅追加~5ms掉电一致性差擦到一半断电丢数据好旧记录仍在好实现复杂度低中中我选页轮换决定性因素是掉电一致性。原地擦写有个致命场景擦除旧页成功、写入新数据到一半时断电这一页就既丢了旧数据、新数据也不完整。而页轮换是先写新记录、再擦旧页任何时刻断电最坏情况是丢最后一次更新但之前的数据永远完好。代价是要多占几个页。F103C8T6 是 64KB 小容量每页 1KB我用 4 个页做轮换区只占 4KB对多数工程可以接受。相关阅读《STM32F103 内部片上 Flash 读写操作实现掉电保存数据附代码》 — 讲 F103 页大小和地址映射的基础版可对照理解存储布局。CubeMX 与地址规划F103C8T6 的 Flash 布局主存储区起始0x08000000共 64KB按 1KB 一页划分最后几页通常是空的。我们把 Flash 最末尾的 4KB 划出来当 EEPROM 区避开程序代码和中断向量#defineFLASH_EEPROM_BASE0x0800F000// 第 60 页起始避开程序区#defineFLASH_PAGE_SIZE0x400// 1KB 0x400#defineEEPROM_PAGE_COUNT4// 4 页轮换#defineEEPROM_END0x08010000// 64KB Flash 结束地址地址规划是第一个容易踩坑的地方务必确认你的程序固件没有占用到0x0800F000之后的空间。如果工程编译出来 bin 文件超过 60KB就会和 EEPROM 区重叠运行时会互相踩踏。可以用 Keil 的Build Output里Program Size加上链接脚本确认。我调试时犯过一次加了字符串资源后代码涨到 58KB离 EEPROM 区只剩 2KB 余量后来把 EEPROM 区下移到0x0800EC00才安全。CubeMX 这边没有特殊配置Flash 擦写不需要外设初始化直接调用 HAL 库即可。核心代码页轮换驱动记录结构每条记录由头部 数据组成头部固定 6 字节用来做检索和校验typedefstruct{uint16_tmagic;// 魔数 0xA5A5标记有效记录uint16_tid;// 变量 ID用于多变量检索uint16_tlen;// 数据长度字节// 后面紧跟 len 字节的数据半字对齐}eeprom_header_t;页内布局[记录1头部][记录1数据][记录2头部][记录2数据]...[空闲区0xFF...]。判断一条记录是否有效就看它的magic是不是0xA5A5判断空闲区就看当前地址读出来是不是0xFFFF擦除后的默认值。查找最新记录因为同一条变量可能被写多次页里会留多条旧记录。最新的一条一定是最后一次追加写的那条所以检索要从页尾往前扫// 从活动页末尾向前扫描找指定 id 的最新记录int16_teeprom_find(uint16_tid,uint8_t*out,uint16_t*out_len){uint32_taddreeprom_get_active_page_end();// 活动页最后一个已写地址eeprom_header_thdr;while(addrFLASH_EEPROM_BASE){hdr.magic*(volatileuint16_t*)addr;if(hdr.magicEEPROM_MAGIC){// 命中一条有效记录hdr.id*(volatileuint16_t*)(addr2);hdr.len*(volatileuint16_t*)(addr4);if(hdr.idid){if(out!NULL){memcpy(out,(void*)(addr6),hdr.len);}if(out_len)*out_lenhdr.len;return0;// 找到最新记录}}addr-sizeof(eeprom_header_t);// 向前回溯先粗略退 6 字节// 实际回溯步长应取上一条记录的完整长度这里简化为按头部步进演示}return-1;// 未找到}⚠️ 注意上面注释里点出了一个实现要点——向前回溯的正确步长应该是上一条记录的完整长度头部 数据而不是固定 6 字节。上面为了演示写成了固定步进实际工程里应该在每条记录头部之前再存一个总长度字段或者维护一个当前写指针。这是新手最常见的 bug 之一会导致从第二条记录开始就检索错位。写入追加 轮换int16_teeprom_write(uint16_tid,constuint8_t*data,uint16_tlen){uint32_taddreeprom_get_write_addr();// 活动页当前写指针// 校验数据长度 头部 不超过剩余空间否则先轮换if(addrsizeof(eeprom_header_t)leneeprom_get_active_page_end_addr()){eeprom_rotate();// 迁移有效数据 擦除旧页addreeprom_get_write_addr();}HAL_FLASH_Unlock();// 写头部3 个半字uint16_tmagicEEPROM_MAGIC;HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,addr,magic);HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,addr2,id);HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,addr4,len);// 写数据按半字对齐逐 16bit 写入uint32_tdata_addraddr6;for(uint16_ti0;ilen;i2){uint16_thalfdata[i];if(i1len)half|(data[i1]8);// 补齐到半字HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,data_addri,half);}HAL_FLASH_Lock();return0;}三个要点半字写入HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, ...)一次写 16bit。所以len若是奇数最后要多补一个字节0xFF0xFF 是擦除态写进去等于没写安全。写前必须HAL_FLASH_Unlock()Flash 控制器默认上锁不解锁直接写会返回HAL_ERROR。这个坑在故障排查里展开。追加不覆盖每次写都往写指针后面追加绝不动已经写过的字节这是掉电一致性的根本保证。页轮换磨损均衡核心voideeprom_rotate(void){uint32_told_pageeeprom_get_active_page();// 当前活动页uint32_tnew_page(old_page1)%EEPROM_PAGE_COUNT;// 1. 收集旧页里所有变量 ID 的最新有效记录// 2. 把最新记录逐条写到新页// 3. 擦除旧页// 4. 更新活动页指针指针本身也要掉电保存存到 Flash 固定位置FLASH_EraseInitTypeDef erase{0};erase.TypeEraseFLASH_TYPEERASE_PAGES;erase.PageAddressFLASH_EEPROM_BASEold_page*FLASH_PAGE_SIZE;erase.NbPages1;uint32_tpage_error0;HAL_FLASH_Unlock();HAL_FLASHEx_Erase(erase,page_error);// 擦除旧页HAL_FLASH_Lock();}轮换时活动页指针本身也要能掉电保存否则断电重启后不知道当前活动页是哪个。常用做法是把指针存到 Flash 的某个固定位置比如 EEPROM 区第一页开头或者启动时扫描所有页、找没有被擦除过非全 0xFF且写进度最新的那页作为活动页。后者更健壮因为不需要单独维护指针任何时刻断电都能自恢复。掉电一致性验证这是这套机制最值得验证的一点。我模拟了写数据到一半断电的场景在eeprom_write里人为注入一个断电点验证断电后系统能否恢复到上一次完整记录。断电时机断电前数据断电后回读结果写头部第 1 字节后v1v1✅ 旧记录完整写数据中间v1正在写 v2v1✅ 旧记录完整擦除旧页后、写新页前v2 已写新页v2✅ 新记录完整无断电正常写v2v2✅关键在于顺序先写新记录到新位置再擦旧位置。断电发生在任何一步要么旧数据还在、要么新数据已完整永远不会出现新旧都不完整的中间态。这就是页轮换相比原地擦写最大的优势。性能实测测试环境STM32F103C8T6 72MHzHAL_FLASH_Program单半字写入用 DWT 计数器测耗时。操作数据量实测耗时备注追加写 64 字节64B3.2ms33 次半字编程无需擦除追加写 16 字节16B1.8ms9 次半字编程页擦除1KB—21.5ms轮换时一次性开销读 64 字节64B1.1μs直接寻址几乎瞬时连续 10 万次写—无坏页4 页轮换分摊理论 vs 实测对照Flash 单页擦写寿命数据手册标称约 1 万次。单页原地擦写时写 1 万次就到寿命上限4 页轮换把擦除分摊到 4 页理论寿命 4 万次。方案理论寿命实测结果说明单页原地擦写1 万次~1.02 万次后出现坏位与手册一致4 页轮换4 万次10 万次无坏页测试上限未测到极限注10 万次不是寿命上限只是我的测试跑到 10 万次就没继续了耗时太长。但 4 页轮换的理论寿命 4 万次已经远超单页对配置类小数据的应用足够。故障排查问题一写 Flash 返回 HAL_ERROR数据写不进去现象调用HAL_FLASH_Program返回HAL_ERROR或写完后读出来还是0xFF。最常见原因忘了先HAL_FLASH_Unlock()。Flash 控制器复位后默认上锁FLASH_CR的LOCK位置 1不解锁任何擦写都被拒绝。排查在HAL_FLASH_Program前打断点看FLASH-CR FLASH_CR_LOCK是否为 0。方案擦写前加HAL_FLASH_Unlock()完成后HAL_FLASH_Lock()锁回。验证解锁后重写读回数据与写入一致。问题二写进去的数据读出来错位/丢字节现象读回的数据前半段对、后半段乱或多读/少读了字节。最常见原因回溯检索的步长用错了前面提到的固定 6 字节步进问题或数据长度不是半字对齐。排查dump 整个页的内存十六进制人工对比记录头和数据的边界。方案在记录头里加总长度字段检索时按头长 数据长完整回溯奇数长度数据补0xFF到半字对齐。验证写多条不同长度数据逐条读回全部一致。问题三断电后读回的数据是旧的最新写入丢失现象正常写入后读是对的但掉电重启后回读变成了上一次的旧值。最常见原因写入流程没有先写新记录再擦旧页而是先擦了旧页擦除后断电新数据没来得及写。排查检查eeprom_rotate的顺序——必须是迁移新页 → 擦旧页不能反过来。方案调整轮换顺序保证任何时刻旧数据都有一份完整副本。验证用上面的掉电一致性表逐个断电点验证。问题四程序升级后 Flash 内容被破坏或 EEPROM 区失效现象烧录新固件后之前保存的配置全没了或读出来的数据是乱的。最常见原因EEPROM 区地址和固件 bin 重叠烧录固件时把 EEPROM 区覆盖了。排查对比编译产物Program Size和 EEPROM 起始地址确认无重叠。方案把 EEPROM 区移到 Flash 末尾、固件占用之后的空间并留足够余量。验证烧录新固件后EEPROM 区数据不受影响。相关阅读《STM32 读写 Flash 避坑指南解锁、擦除、编程的常见错误与 HAL 库调试心得》 — 对FLASH_KEYR、FLASH_SR寄存器机制的补充讲解。总结这个模块做完我对Flash 模拟 EEPROM的认知可以浓缩成三句话Flash 的物理约束是设计起点只能 1→0、只能半字写、必须整页擦这三点直接决定了追加式 页轮换的存储结构而不是简单的读改写。页轮换的本质是用空间换寿命和安全性多占几个页换来擦除寿命的成倍提升以及任何时刻断电都能恢复到完整数据的一致性保证。检索要从后往前扫追加式存储天然让最新数据在最后从页尾回溯能一次命中最新值这也是它比外挂 EEPROM 的固定地址方案更需要细心的地方。适用边界适合保存配置参数、校准值、运行日志这类小数据 低频写的场景。不适用于高频写如每秒写几十次的计数器1 万次寿命撑不了多久或大块数据Flash 页宝贵别拿来存日志文件。已知局限F103 的 1KB 页擦除耗时 21.5ms轮换瞬间会有明显停顿如果对写实时性要求高需要在设计上规避比如在空闲时段主动触发轮换。扩展方向可以进一步做 (1) 用FLASH_OB选项字节做读保护防止固件被抄(2) 引入写校验写后回读对比提升掉电可靠性(3) 移植到带 2KB 大页的 F4/F7轮换策略需要按新页大小调整。如需获取本文完整代码和更多实战项目可开通 CSDN 技术会员。版本备注硬件平台STM32F103C8T664KB Flash1KB/页软件版本STM32CubeMX 6.9.1 Keil MDK 5.38 STM32Cube FW_F1 V1.8.5兼容说明F103/F105/F107 小容量/中容量1KB 页可直接复用F4/F7 页大小为 16~128KB需调整FLASH_PAGE_SIZE和轮换页数