简介本资源是一套面向嵌入式物联网设备开发者的STM32G071平台FLASH存储优化实践方案聚焦单片机片内FLASH模拟EEPROM的高可靠性实现解决频繁写入导致的擦写寿命瓶颈问题。方案采用轮询式地址索引管理与智能页擦除调度策略将有效擦写次数提升至百万级显著延长终端设备在无外置EEPROM场景下的服役周期适用于智能传感、远程抄表、边缘节点等低功耗长寿命应用场景。压缩包共1236个文件含664个C源码含HAL驱动与算法核心、261个头文件定义数据结构与接口、104个汇编启动文件及调试/构建相关文件如.axf、.hex、.uvprojx等整体大小20.96MB工程结构完整支持IAR与Keil双环境编译。已有32人学习下载提供可直接集成的Flash模拟EEPROM中间件、多页冗余管理逻辑、磨损均衡算法实现及配套测试用例代码注释详尽便于理解存储状态机设计与页映射机制。1. 项目概述与核心价值最近在做一个物联网传感器节点的项目节点需要记录一些校准参数、运行状态和事件日志。这类数据的特点是单个体积不大几十到几百字节但需要频繁更新并且要求掉电不丢失。一开始自然想到了外挂一颗EEPROM芯片但为了省下那几毛钱的BOM成本和宝贵的PCB面积我决定在STM32G071这颗芯片自带的FLASH上动动脑筋。直接用FLASH存这些频繁改动的数据最怕的就是把FLASH写“废”了。FLASH的擦写寿命通常只有1万到10万次而我的节点可能一天就要更新状态上百次。如果像操作RAM一样随便写几个月就够呛。所以这个项目的核心目标就变成了如何在单片机的内部FLASH上实现一种可靠、高效、且能大幅延长存储寿命的“模拟EEPROM”方案最终目标是让等效擦写寿命达到百万次级别满足大多数物联网设备的长期可靠运行需求。我选择了STM32G071作为硬件平台一方面是因为它性价比高在物联网领域很常见另一方面它的FLASH结构清晰便于我们实施精细化管理。整个方案我称之为“轮询式FLASH模拟EEPROM”其精髓在于两点一是地址索引管理避免对单一地址的反复擦写二是智能的页擦除策略将擦除操作平摊到整个存储区域。下面我就把这套方案的实现思路、关键代码和踩过的坑毫无保留地分享出来。2. 方案设计与核心思路拆解2.1 为什么是“模拟EEPROM”标准的EEPROM和FLASH虽然都是非易失性存储器但底层操作机制有本质区别这也是我们所有优化算法的出发点。EEPROM的特性可以按字节Byte进行写入和擦除。你想改某个地址的数据直接写就行控制器内部会先擦除该字节再写入新值。这种特性使得它对频繁修改的小数据非常友好但缺点是成本高、密度低。FLASH的特性操作单位是“页Page”和“字Word”。写入前目标区域必须处于“已擦除”状态通常为0xFF。擦除的最小单位是一页STM32G071是2KB而写入的最小单位通常是一个字32位或64位。最要命的是FLASH的擦除寿命远低于写入寿命。一次页擦除对寿命的消耗远大于成百上千次的字写入。因此“模拟EEPROM”的核心矛盾就是我们要用“页擦除”和“字写入”这两种粗粒度的操作去模拟“字节擦写”这种细粒度的行为同时还要规避FLASH寿命短的短板。2.2 轮询式存储与地址索引管理最朴素的想法是划出一页FLASH2KB专门存数据。当某个数据需要更新时就在这页里找个新位置写入。但这会带来两个问题1. 如何知道最新数据在哪2. 页写满了怎么办我的解决方案是引入地址索引表和轮询写入机制。1. 虚拟地址与物理地址映射 对于应用层来说它只知道一些“变量名”或“虚拟地址”比如PARAM_CALIBRATIONLOG_COUNTER。我们维护一个静态的映射表将这些虚拟项映射到一个固定的“数据ID”上。这个ID是逻辑上的不直接对应物理地址。2. 物理存储结构设计 我划出了连续的多页FLASH作为存储池Pool例如4页8KB。每一页都被格式化成固定大小的“存储单元Cell”每个单元用来存储一个“数据ID”对应的单次数据记录。一个单元包含三部分头部Header包含数据ID、序列号或时间戳、状态标记如有效、无效、已删除。数据区Data存储实际的数据内容。CRC校验区可选用于验证数据的完整性。3. 轮询写入过程 当需要更新某个数据ID的值时算法不会去覆盖旧值而是执行以下步骤在存储池中寻找“空闲”或“标记为无效”的单元。将新的数据含更新的头部和数据写入找到的这个单元。将之前该数据ID对应的那个单元标记为“无效”。 这样同一个数据ID的最新值永远存储在最后一次写入的那个单元里。物理地址像指针一样在存储池中轮询移动避免了固定地址的反复磨损。2.3 页擦除策略与垃圾回收随着轮询写入的进行存储池中的“无效”单元会越来越多可用的“空闲”单元会越来越少。当空闲单元低于某个阈值或者干脆找不到空闲单元时就必须进行“垃圾回收Garbage Collection”也就是执行页擦除操作。智能页擦除策略是关键目标是将擦除操作均匀分布到所有页上实现“磨损均衡Wear Leveling”。我的策略是这样的状态跟踪为存储池中的每一页维护一个元信息记录该页的“无效单元计数”和“擦除次数”。触发条件当整个存储池的空闲单元比例低于20%时触发垃圾回收流程。页选择算法不是简单地擦除无效单元最多的页。我的算法会综合考虑两个因素无效单元密度优先选择无效单元最多的页这样一次擦除能释放最多空间。历史擦除次数引入一个权重让擦除次数较少的页有更高的概率被选中。这实现了初步的磨损均衡。 通过一个简单的加权评分例如分数 无效单元数量 * 权重1 - 擦除次数 * 权重2选择分数最高的页作为目标页。数据搬迁与擦除选定目标页后先将该页中所有仍为“有效”状态的数据单元搬迁到存储池的其他空闲单元中。搬迁完成后确保目标页上的所有有效数据都已安全转移然后才执行页擦除Page Erase命令。擦除后该页所有单元恢复为“空闲”状态可重新投入使用。元信息更新更新该页的擦除次数计数器。通过这种策略擦除操作被动态地分摊到所有页上。即使某些数据更新极其频繁其对应的无效单元会分散在不同页中不会导致某一页被过早擦除报废。这是将寿命从“万次”提升到“百万次”级别的核心。3. 基于STM32G071的具体实现3.1 硬件与存储规划STM32G071的FLASH主存储块Main Memory大小为64KB页大小为2KB。我的规划如下程序区占用前32KB16页用于存放应用程序。模拟EEPROM存储池从第16页开始连续占用4页页地址0x08008000 - 0x0800A000总计8KB。备份区可选预留最后1-2页用于存储存储池的关键元数据如各页擦除计数、全局版本号防止运行时数据丢失。这部分数据更新不频繁可以直接写。注意FLASH的页地址和大小一定要根据你所用的具体STM32型号的参考手册Reference Manual来确认不同系列、不同容量的芯片可能会有差异。务必在stm32g0xx_hal_flash.h和相关数据手册中核对清楚。3.2 关键数据结构定义在代码中我首先定义了核心的数据结构。/* flash_emul_eeprom.h */ typedef enum { CELL_STATE_FREE 0xFF, // 空闲可写入 CELL_STATE_VALID 0xAA, // 数据有效 CELL_STATE_INVALID 0x55, // 数据无效旧数据 CELL_STATE_ERASED 0x00 // 已擦除实际FLASH擦除后为0xFF此为逻辑状态 } CellState_t; typedef struct { uint16_t data_id; // 数据标识符 (0~65535) uint16_t seq_num; // 序列号用于解决同时写入冲突或作为时间戳 uint8_t state; // 单元状态 (CellState_t) uint8_t data_len; // 实际数据长度 (字节) uint8_t data[EMULATED_DATA_MAX_LEN]; // 数据载荷假设最大64字节 uint32_t crc32; // 对整个单元除CRC外的校验和 } FlashCell_t; // 一个存储单元 #define FLASH_PAGE_SIZE 2048U // STM32G071一页2KB #define CELLS_PER_PAGE (FLASH_PAGE_SIZE / sizeof(FlashCell_t)) // 每页能存的单元数 #define STORAGE_POOL_START_PAGE 16 // 存储池起始页号 #define STORAGE_POOL_PAGE_NUM 4 // 存储池总页数 #define STORAGE_POOL_START_ADDR (0x08000000UL (STORAGE_POOL_START_PAGE * FLASH_PAGE_SIZE))3.3 核心操作函数实现3.3.1 初始化与状态扫描系统启动时必须对存储池进行扫描在内存中重建出当前所有数据的“最新位置”索引表。/* flash_emul_eeprom.c */ static uint32_t latest_cell_addr[MAX_DATA_ID_NUM]; // 索引表data_id - 最新单元物理地址 void FlashEE_Init(void) { uint32_t page_addr; FlashCell_t *p_cell; uint32_t cell_offset; // 清空内存索引表 memset(latest_cell_addr, 0xFF, sizeof(latest_cell_addr)); // 遍历存储池每一页的每一个单元 for (int page 0; page STORAGE_POOL_PAGE_NUM; page) { page_addr STORAGE_POOL_START_ADDR page * FLASH_PAGE_SIZE; for (int i 0; i CELLS_PER_PAGE; i) { cell_offset i * sizeof(FlashCell_t); p_cell (FlashCell_t *)(page_addr cell_offset); // 检查单元头部的状态标记 if (p_cell-state CELL_STATE_VALID) { // 计算CRC验证数据完整性 uint32_t calc_crc Calculate_CRC32((uint8_t*)p_cell, sizeof(FlashCell_t)-4); if (calc_crc p_cell-crc32) { // 数据有效且完整更新索引表 // 如果同一个data_id有多个有效单元序列号seq_num大的为最新 uint32_t old_addr latest_cell_addr[p_cell-data_id]; if (old_addr 0xFFFFFFFF) { latest_cell_addr[p_cell-data_id] (uint32_t)p_cell; } else { FlashCell_t *p_old_cell (FlashCell_t *)old_addr; if (p_cell-seq_num p_old_cell-seq_num) { latest_cell_addr[p_cell-data_id] (uint32_t)p_cell; // 可选将旧单元标记为INVALID需谨慎涉及写操作 } } } else { // CRC校验失败标记为无效可选需写操作 } } } } // 扫描完成后内存中的latest_cell_addr表就记录了所有有效数据的最新位置 }实操心得初始化扫描是比较耗时的操作尤其是存储池较大时。可以在初始化时只做快速扫描比如只检查状态字等第一次读取数据时再做完整的CRC校验。或者可以将索引表本身也作为一个“数据”保存在存储池里每次更新时也更新索引表启动时直接读取索引表即可但这增加了写操作的复杂性。3.3.2 数据写入流程这是最核心的函数实现了轮询写入和垃圾回收触发。int FlashEE_Write(uint16_t data_id, uint8_t *p_data, uint8_t len) { HAL_StatusTypeDef hal_status; uint32_t free_cell_addr 0xFFFFFFFF; FlashCell_t new_cell; uint32_t page_to_erase; // 1. 参数检查 if (data_id MAX_DATA_ID_NUM || len EMULATED_DATA_MAX_LEN || p_data NULL) { return FLASH_EE_ERR_PARAM; } // 2. 寻找一个空闲单元 free_cell_addr FindFreeCell(); if (free_cell_addr 0xFFFFFFFF) { // 没有找到空闲单元触发垃圾回收 page_to_erase SelectPageForGC(); if (page_to_erase 0xFFFFFFFF) { return FLASH_EE_ERR_NO_SPACE; // 垃圾回收也无法释放空间理论上不应发生 } // 执行垃圾回收搬迁有效数据并擦除页 if (PerformGarbageCollection(page_to_erase) ! FLASH_EE_OK) { return FLASH_EE_ERR_GC_FAILED; } // 垃圾回收后再找一次空闲单元 free_cell_addr FindFreeCell(); if (free_cell_addr 0xFFFFFFFF) { return FLASH_EE_ERR_NO_SPACE; } } // 3. 准备新单元数据 new_cell.data_id data_id; new_cell.seq_num GetNextSequenceNumber(); // 获取一个递增的序列号 new_cell.state CELL_STATE_VALID; new_cell.data_len len; memcpy(new_cell.data, p_data, len); new_cell.crc32 Calculate_CRC32((uint8_t*)new_cell, sizeof(FlashCell_t)-4); // 4. 解锁FLASH并写入 HAL_FLASH_Unlock(); uint64_t cell_data_u64; uint8_t *p_src (uint8_t*)new_cell; uint32_t *p_dst (uint32_t*)free_cell_addr; for (int i 0; i sizeof(FlashCell_t); i 8) { // STM32G071 FLASH编程宽度为64位8字节 memcpy(cell_data_u64, p_src i, 8); hal_status HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, (uint32_t)(p_dst i/4), cell_data_u64); if (hal_status ! HAL_OK) { HAL_FLASH_Lock(); return FLASH_EE_ERR_WRITE_FAILED; } } HAL_FLASH_Lock(); // 5. 更新内存索引表并将旧单元标记为无效 uint32_t old_addr latest_cell_addr[data_id]; latest_cell_addr[data_id] free_cell_addr; if (old_addr ! 0xFFFFFFFF) { // 将旧单元的状态字改为INVALID这是一个单独的64位或32位写操作需再次解锁FLASH MarkCellAsInvalid(old_addr); } return FLASH_EE_OK; }3.3.3 垃圾回收实现static uint32_t SelectPageForGC(void) { uint32_t selected_page 0xFFFFFFFF; int32_t max_score -1; int32_t score; for (int page 0; page STORAGE_POOL_PAGE_NUM; page) { uint32_t page_addr STORAGE_POOL_START_ADDR page * FLASH_PAGE_SIZE; int invalid_count CountInvalidCellsInPage(page_addr); int erase_count GetPageEraseCount(page); // 从元数据区或RAM缓存读取 // 简单的加权评分算法 score invalid_count * 10 - erase_count * 1; // 权重可调 if (score max_score invalid_count 0) { // 只选择有无效单元的页 max_score score; selected_page page; } } return selected_page; // 返回页号 } static int PerformGarbageCollection(uint32_t page_num) { uint32_t page_addr STORAGE_POOL_START_ADDR page_num * FLASH_PAGE_SIZE; FlashCell_t *p_cell; // 1. 搬迁该页所有有效单元 for (int i 0; i CELLS_PER_PAGE; i) { p_cell (FlashCell_t *)(page_addr i * sizeof(FlashCell_t)); if (p_cell-state CELL_STATE_VALID) { // 验证CRC if (Calculate_CRC32((uint8_t*)p_cell, sizeof(FlashCell_t)-4) p_cell-crc32) { // 将该有效数据写入新的空闲单元递归调用或复用Write逻辑 int ret FlashEE_Write(p_cell-data_id, p_cell-data, p_cell-data_len); if (ret ! FLASH_EE_OK) { // 搬迁失败需要回滚或报错 return FLASH_EE_ERR_GC_MIGRATE; } } // 无论CRC是否通过原单元在擦除后都会消失 } } // 2. 擦除该页 HAL_FLASH_Unlock(); FLASH_EraseInitTypeDef EraseInitStruct; uint32_t PageError; EraseInitStruct.TypeErase FLASH_TYPEERASE_PAGES; EraseInitStruct.Page page_num STORAGE_POOL_START_PAGE; // 注意HAL库的Page参数是绝对页号 EraseInitStruct.NbPages 1; if (HAL_FLASHEx_Erase(EraseInitStruct, PageError) ! HAL_OK) { HAL_FLASH_Lock(); return FLASH_EE_ERR_ERASE_FAILED; } HAL_FLASH_Lock(); // 3. 更新该页的擦除计数写入元数据区 IncrementPageEraseCount(page_num); return FLASH_EE_OK; }4. 性能优化与关键问题排查4.1 如何计算并验证“百万次寿命”假设我们规划了4页8KB存储池每页2KB每个存储单元大小为sizeof(FlashCell_t) 76字节估算。那么每页可容纳单元数CELLS_PER_PAGE≈ 2048 / 76 ≈ 26个。单页擦除寿命以STM32G071典型的10万次1e5计算。系统总擦除次数4页 * 10万次/页 40万次。磨损均衡效果由于我们的页选择算法擦除操作被相对均匀地分配到4页上。理想情况下每页被擦除的次数接近系统总擦除次数的1/4即10万次。等效字节擦写次数这是关键。每次应用层更新一个数据我们并不是擦除一页而是写入一个新单元约76字节。只有当存储池快满时才触发一次页擦除。一次页擦除可以释放一整页26个单元的空间。最坏情况每次写入后存储池都刚好满触发GC。那么一次应用层写操作 ≈ 一次页擦除 / 26。系统总等效写操作次数 ≈ 40万次页擦除 * 26单元/页 ≈1040万次。考虑写放大实际上由于无效数据的存在一次GC可能只释放部分空间存在“写放大”。但即使考虑2-3倍的写放大等效擦写次数也轻松超过百万次。注意事项这个计算是理论值。实际寿命受FLASH个体差异、工作温度、电压稳定性影响。在关键应用中建议留有3-5倍的设计余量并且避免在极端环境下进行频繁的FLASH操作。4.2 常见问题与调试技巧问题1数据写入后读取错误或CRC校验失败。可能原因1FLASH未解锁或编程对齐错误。STM32的FLASH编程有严格的地址和宽度对齐要求通常是64位或32位。确保你的写入地址是8字节对齐的并且每次写入8字节数据。排查检查HAL_FLASH_Program函数的参数特别是地址和数据。使用调试器查看目标地址处的数据是否与预期一致。可能原因2中断打断写操作。FLASH编程期间必须禁止所有中断包括SysTick。排查在HAL_FLASH_Unlock()和HAL_FLASH_Lock()之间调用__disable_irq()和__enable_irq()。__disable_irq(); HAL_FLASH_Unlock(); // ... 编程操作 ... HAL_FLASH_Lock(); __enable_irq();问题2垃圾回收时系统卡死或重启。可能原因递归调用或栈溢出。PerformGarbageCollection中调用了FlashEE_Write而FlashEE_Write在找不到空间时又会触发PerformGarbageCollection形成递归。如果GC后空间仍不足会导致无限递归。解决在FlashEE_Write中进入GC前设置一个标志位如in_gc_flag在GC期间尝试写入新数据时如果是因为GC触发的写入则直接写入回收后的页避免再次触发GC。或者确保GC总能释放出至少一个空闲单元。问题3存储池很快被写满寿命未达预期。可能原因无效单元标记失败或索引表错误。导致系统无法识别出无效单元GC时无法释放空间。排查定期或通过调试命令输出存储池的状态快照每页的有效、无效、空闲单元数量。检查内存索引表latest_cell_addr是否正确。确认MarkCellAsInvalid函数确实成功将旧单元的状态字改写了。问题4功耗敏感设备FLASH操作电流大。优化FLASH擦除和编程时功耗较高。可以设置“懒惰GC”策略比如空闲单元低于5%时才触发而不是20%。或者将GC操作放在设备唤醒、连接电源等功耗不敏感的时刻进行。4.3 高级优化技巧序列号防回滚seq_num不仅用于判断新旧还可以防止意外断电导致的数据回滚。每次写入使用一个单调递增的序列号存储在备份寄存器或另一块FLASH中即使旧数据的物理位置更新了其序列号也小于新数据可以可靠识别。元数据存储优化页擦除计数等元数据如果频繁更新也会消耗FLASH寿命。可以将其存储在另一页中并采用类似的轮询存储策略或者使用STM32的备份寄存器BKP如果可用。数据压缩对于存储的数据如果存在大量重复或可压缩模式可以在写入前进行简单的压缩如Run-Length Encoding减少写入量间接提升寿命。掉电保护在写入或擦除过程中掉电可能导致FLASH内容处于不可预测状态。可以在关键操作序列如“标记旧数据无效-写新数据”中引入原子性设计例如先写一个“事务开始”标记操作完成后再写“事务结束”标记。启动时检查到未完成的事务可以进行回滚或修复。5. 实测效果与项目总结我将这套方案应用在了那个物联网传感器节点上持续运行了三个月。通过日志统计平均每天写入约200次数据。我预留了4页8KB存储池。理论计算和实际监测表明存储池利用率始终在70%-80%之间波动垃圾回收大约每2-3天自动触发一次。磨损均衡通过读取各页的软件擦除计数4页的计数差值在15%以内说明页选择算法工作良好。数据可靠性期间进行了多次强制断电测试上电后所有参数和状态记录均能正确恢复未发生数据错乱或丢失。性能影响单次写入操作找到空闲单元并写入耗时在10ms左右主要耗时在FLASH编程。垃圾回收过程搬迁擦除耗时约100ms但发生频率低对整体业务无感知影响。这个项目让我深刻体会到嵌入式开发中的资源优化往往就是“螺蛳壳里做道场”。放弃一颗外置EEPROM换来的是对MCU内部资源更深入的理解和掌控。这套“轮询式FLASH模拟EEPROM”方案其价值不仅仅在于节省成本更在于它提供了一种在资源受限环境下实现高可靠数据存储的设计范式。对于STM32G0、G4甚至F1系列等没有真正EEPROM的芯片这套方案都具有很强的参考意义。最后分享一个调试时的小技巧务必实现一个通过串口输出存储池完整映像的函数。当出现任何数据异常时将这个十六进制dump保存下来与你的内存索引表进行比对几乎所有逻辑错误都能一目了然。这比在调试器里一个个地址查看要高效得多。本文还有配套的精品资源点击获取