摘要

STM32F103 系列芯片没有集成 EEPROM，但很多产品又需要掉电保存校准参数、用户配置和运行日志这类小数据。本文基于 STM32F103C8T6 的 64KB 内部 Flash，用 HAL 库实现一套带磨损均衡的"Flash 模拟 EEPROM"模块：通过页轮换算法把 4 个 1KB 页组织成虚拟存储空间，配合头部元数据管理有效记录。实测单次写 64 字节耗时约 3.2ms、读耗时约 1.1μs，连续 10 万次写入无坏页、上电回读数据 100% 一致；把擦写寿命从单页固定的 1 万次提升到理论上 4 万次。文末附完整驱动代码、擦写时序实测数据，以及"写保护、半字写入、页错位"三类高频故障的排查过程。

为什么不用外挂 EEPROM

做带配置功能的产品时，最常见的需求就是"设置项掉电不丢"。摆在面前的方案有两条：

1. 外挂 24C02 这类 I2C EEPROM：字节级可擦写、寿命 100 万次，但要多一颗芯片、多两根线、多写一套 I2C 驱动。
2. 用内部 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 半字写入。下面是这套模块的存储布局：

核心思想一句话概括：永远只往"活动页"追加写，不原地改写；写满一页就把最新的有效数据搬到下一页，再擦掉旧页。这样每页的擦除次数就被分摊了。

Flash 的两个硬约束

写代码前，必须把这两条物理特性刻进脑子里，否则后面所有坑都源于此：

1. 只能从 1 写 0，不能从 0 写 1：Flash 编程只能把某位从 1 置 0，想把 0 改回 1 必须整页擦除。所以"原地改一个字节"在 Flash 上根本做不到，擦除后整页全是0xFF。
2. 写入粒度是半字（16bit）：STM32F103 的 Flash 只能按 16bit 编程，不能按字节写。所以一个 8bit 的数据也要凑成 16bit 再写。

这两条决定了我们的存储结构必须"追加式 + 半字对齐"。下面讲实现时会反复用到。

设计决策：页轮换 vs 原地擦写 vs 外挂 EEPROM

我选页轮换，决定性因素是掉电一致性。原地擦写有个致命场景：擦除旧页成功、写入新数据到一半时断电，这一页就既丢了旧数据、新数据也不完整。而页轮换是"先写新记录、再擦旧页"，任何时刻断电，最坏情况是丢最后一次更新，但之前的数据永远完好。

代价是要多占几个页。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_taddr=eeprom_get_active_page_end();// 活动页最后一个已写地址eeprom_header_thdr;while(addr>=FLASH_EEPROM_BASE){hdr.magic=*(volatileuint16_t*)addr;if(hdr.magic==EEPROM_MAGIC){// 命中一条有效记录hdr.id=*(volatileuint16_t*)(addr+2);hdr.len=*(volatileuint16_t*)(addr+4);if(hdr.id==id){if(out!=NULL){memcpy(out,(void*)(addr+6),hdr.len);}if(out_len)*out_len=hdr.len;return0;// 找到最新记录}}addr-=sizeof(eeprom_header_t);// 向前回溯（先粗略退 6 字节）// 实际回溯步长应取上一条记录的完整长度，这里简化为按头部步进演示}return-1;// 未找到}

⚠️ 注意：上面注释里点出了一个实现要点——向前回溯的正确步长应该是"上一条记录的完整长度"（头部 + 数据），而不是固定 6 字节。上面为了演示写成了固定步进，实际工程里应该在每条记录头部之前再存一个"总长度"字段，或者维护一个"当前写指针"。这是新手最常见的 bug 之一，会导致从第二条记录开始就检索错位。

写入（追加 + 轮换）

int16_teeprom_write(uint16_tid,constuint8_t*data,uint16_tlen){uint32_taddr=eeprom_get_write_addr();// 活动页当前写指针// 校验：数据长度 + 头部 不超过剩余空间，否则先轮换if(addr+sizeof(eeprom_header_t)+len>eeprom_get_active_page_end_addr()){eeprom_rotate();// 迁移有效数据 + 擦除旧页addr=eeprom_get_write_addr();}HAL_FLASH_Unlock();// 写头部（3 个半字）uint16_tmagic=EEPROM_MAGIC;HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,addr,magic);HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,addr+2,id);HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,addr+4,len);// 写数据（按半字对齐，逐 16bit 写入）uint32_tdata_addr=addr+6;for(uint16_ti=0;i<len;i+=2){uint16_thalf=data[i];if(i+1<len)half|=(data[i+1]<<8);// 补齐到半字HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD,data_addr+i,half);}HAL_FLASH_Lock();return0;}

三个要点：

1. 半字写入：HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, ...)一次写 16bit。所以len若是奇数，最后要多补一个字节0xFF（0xFF 是擦除态，写进去等于没写，安全）。
2. 写前必须HAL_FLASH_Unlock()：Flash 控制器默认上锁，不解锁直接写会返回HAL_ERROR。这个坑在故障排查里展开。
3. 追加不覆盖：每次写都往写指针后面追加，绝不动已经写过的字节，这是掉电一致性的根本保证。

页轮换（磨损均衡核心）

voideeprom_rotate(void){uint32_told_page=eeprom_get_active_page();// 当前活动页uint32_tnew_page=(old_page+1)%EEPROM_PAGE_COUNT;// 1. 收集旧页里所有变量 ID 的最新有效记录// 2. 把最新记录逐条写到新页// 3. 擦除旧页// 4. 更新活动页指针（指针本身也要掉电保存，存到 Flash 固定位置）FLASH_EraseInitTypeDef erase={0};erase.TypeErase=FLASH_TYPEERASE_PAGES;erase.PageAddress=FLASH_EEPROM_BASE+old_page*FLASH_PAGE_SIZE;erase.NbPages=1;uint32_tpage_error=0;HAL_FLASH_Unlock();HAL_FLASHEx_Erase(&erase,&page_error);// 擦除旧页HAL_FLASH_Lock();}

轮换时"活动页指针"本身也要能掉电保存，否则断电重启后不知道当前活动页是哪个。常用做法是把指针存到 Flash 的某个固定位置（比如 EEPROM 区第一页开头），或者启动时扫描所有页、找"没有被擦除过（非全 0xFF）且写进度最新"的那页作为活动页。后者更健壮，因为不需要单独维护指针，任何时刻断电都能自恢复。

掉电一致性验证

这是这套机制最值得验证的一点。我模拟了"写数据到一半断电"的场景：在eeprom_write里人为注入一个断电点，验证断电后系统能否恢复到上一次完整记录。

关键在于顺序：先写新记录到新位置，再擦旧位置。断电发生在任何一步，要么旧数据还在、要么新数据已完整，永远不会出现"新旧都不完整"的中间态。这就是页轮换相比原地擦写最大的优势。

性能实测

测试环境：STM32F103C8T6 @72MHz，HAL_FLASH_Program单半字写入，用 DWT 计数器测耗时。

理论 vs 实测对照

Flash 单页擦写寿命数据手册标称约 1 万次。单页原地擦写时，写 1 万次就到寿命上限；4 页轮换把擦除分摊到 4 页，理论寿命 4 万次。

注：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"的认知可以浓缩成三句话：

1. Flash 的物理约束是设计起点：只能 1→0、只能半字写、必须整页擦，这三点直接决定了"追加式 + 页轮换"的存储结构，而不是简单的"读改写"。
2. 页轮换的本质是"用空间换寿命和安全性"：多占几个页，换来擦除寿命的成倍提升，以及任何时刻断电都能恢复到完整数据的一致性保证。
3. 检索要从后往前扫：追加式存储天然让"最新数据在最后"，从页尾回溯能一次命中最新值，这也是它比外挂 EEPROM 的固定地址方案更需要细心的地方。

适用边界：适合保存配置参数、校准值、运行日志这类小数据 + 低频写的场景。不适用于高频写（如每秒写几十次的计数器，1 万次寿命撑不了多久）或大块数据（Flash 页宝贵，别拿来存日志文件）。

已知局限：F103 的 1KB 页擦除耗时 21.5ms，轮换瞬间会有明显停顿，如果对写实时性要求高，需要在设计上规避（比如在空闲时段主动触发轮换）。

扩展方向：可以进一步做 (1) 用FLASH_OB选项字节做读保护，防止固件被抄；(2) 引入写校验（写后回读对比），提升掉电可靠性；(3) 移植到带 2KB 大页的 F4/F7，轮换策略需要按新页大小调整。

如需获取本文完整代码和更多实战项目，可开通 CSDN 技术会员。

📝版本备注

• 硬件平台：STM32F103C8T6（64KB Flash，1KB/页）
• 软件版本：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和轮换页数