当前位置：首页 > news >正文

STM32 Flash模拟EEPROM：轻量级磨损均衡算法实现与避坑指南

news 2026/7/29 6:29:55

1. 项目缘起：为什么要在STM32的Flash里“模拟”EEPROM？

如果你用过STM32做项目，尤其是需要掉电保存一些参数、配置或者运行记录的时候，大概率会碰到一个头疼的问题：STM32本身没有硬件EEPROM。官方的解决方案通常是推荐你外挂一颗像AT24C02这样的I2C EEPROM芯片。这方案稳是稳，但成本上去了，PCB面积占用了，还得额外处理I2C的通信和潜在的地址冲突、上拉电阻等问题。对于成本敏感或者空间极度受限的项目，多一颗芯片都是负担。

于是，一个很自然的想法就冒出来了：能不能用STM32片内自带的Flash来“充当”EEPROM用？反正都是非易失性存储器，掉电数据不丢。这个想法本身没问题，很多开发者都在这么做。但真正动手去写这个“Flash模拟EEPROM”的驱动时，你很快就会撞上Flash和EEPROM最核心的一个差异：擦写寿命。

普通的EEPROM，比如AT24C02，标称擦写寿命是100万次。而STM32内部的Flash，根据数据手册，通常只有1万到10万次（不同系列、不同工艺有差异）。如果你简单地把某个Flash扇区（Sector）固定当作EEPROM来反复擦写，比如用来存储一个频繁更新的系统运行时间计数器，可能用不了几个月，那个扇区就“写废了”，导致数据丢失，产品返修。

这就是“磨损均衡”算法必须登场的原因。它的核心目标就一句话：把有限的擦写次数，平均分摊到一大片Flash区域上，从而在整体上大幅延长这个“模拟EEPROM”的使用寿命。这就像你有一件非常不耐磨的衣服，如果总磨一个地方，很快就破洞。但如果你能让全身均匀地承受摩擦，这件衣服的整体寿命就会长很多。

我最近在一个电池管理设备上就用了这个方案。设备需要每秒钟记录一次电池电压、电流等关键数据，并掉电保存最后1000条记录。如果外挂EEPROM，容量和成本都不划算。最终，我选择在STM32F103的128K Flash里划出16K作为“虚拟EEPROM”区域，并实现了一套轻量级的磨损均衡算法。实测下来，效果非常稳定，完全满足了产品需求。下面，我就把这套方案的实现思路、关键细节和踩过的坑，毫无保留地分享出来。

2. Flash与EEPROM的底层差异：不只是寿命那么简单

在动手写代码之前，我们必须彻底理解Flash和EEPROM在物理特性上的不同。这决定了我们算法设计的边界，很多“坑”都源于对底层机制的一知半解。

2.1 物理结构的根本区别

EEPROM（Electrically Erasable Programmable Read-Only Memory）允许按字节（Byte）擦除和编程。你可以单独把地址0x1000的一个字节从0xFF改成0x00，再单独改回来，对其他字节毫无影响。这种灵活性是它寿命长的物理基础。

而Flash存储器，无论是NOR还是NAND，其基本擦除单位是扇区（Sector）或块（Block），编程（写入）的最小单位通常是字（Word，如32位）或页（Page）。对于STM32，我们操作的是NOR Flash。以常见的STM32F1系列为例：

写入：必须以**半字（16位）或字（32位）**为单位进行。你不能单独写一个字节。如果你尝试写一个字节，实际上需要先读出这个字，修改对应的字节，然后再整个字写回去。
擦除：必须以扇区为单位。STM32F103C8T6的Flash，前16K字节被分为4个4K的扇区，后面扇区大小可能是64K或128K。擦除一个扇区，会把该扇区内所有位变成1（状态为0xFF）。

这就引出了第一个关键约束：我们的“虚拟EEPROM”管理单元，必须与Flash的擦除单元（扇区）对齐。我们是在管理几个、十几个甚至几十个Flash扇区，而不是直接管理字节。

2.2 操作特性与“写前需擦”的陷阱

Flash有一个铁律：只能把位从1写成0，不能从0写成1。要把0变回1，唯一的办法就是执行扇区擦除操作。这带来了一个经典的操作顺序：写数据前，必须先确保目标区域是已擦除状态（全0xFF）。

假设我们想在一个地址上更新数据。简单流程是：

备份该地址所在扇区的其他有效数据。
擦除整个扇区。
将新数据连同备份的其他数据，一起写回该扇区。

如果你直接在未擦除的区域（有0的位）上写入，会导致写入失败或数据错误。STM32的Flash编程接口在写入时会检查目标地址的数据，如果发现不是0xFFFF，通常会触发错误或直接忽略本次写入。很多初学者驱动写不进去，问题就出在这里——没有确保写入地址是“干净的”（0xFF）。

2.3 寿命的量化评估与设计目标

假设我们选用STM32F103，其Flash擦写寿命标称是1万次（10k cycles）。如果我们用一个4K的扇区来存储一个需要每秒更新一次的数据：

寿命 = 10,000次 / (1次/秒) = 10,000秒 ≈ 2.78小时。显然，这完全不可用。

如果我们通过磨损均衡算法，将擦写操作分摊到N个扇区上，那么总的有效擦写寿命就变成了：

总寿命 ≈ 单个扇区寿命 × 扇区数量。如果我们用8个4K的扇区（共32K）来做这个虚拟EEPROM池：
总寿命 ≈ 10,000 × 8 = 80,000次。
对于每秒更新一次的数据，寿命可达80,000秒 ≈ 22.2小时。虽然还是不够，但已经提升了8倍。

但这只是理想情况。实际上，磨损均衡算法本身有开销（管理数据也要占空间），而且数据更新频率和分布是不均匀的。我们的设计目标，就是通过更精巧的算法，让这个“寿命放大系数”尽可能接近扇区数量N，同时保证数据的一致性和可靠性。

3. 磨损均衡算法设计：从“轮询”到“状态机”

市面上有很多成熟的磨损均衡算法，比如应用于SD卡、U盘的FTL（Flash Translation Layer）层算法，但它们通常比较复杂，需要维护庞大的映射表。对于资源有限的单片机，我们需要一个极度轻量、 deterministic（确定性）、且对RAM消耗极小的方案。

3.1 扇区池与“活动扇区”概念

首先，我们在Flash中划出一块连续的地址空间作为“虚拟EEPROM池”，例如从0x08010000开始的32K空间，它由8个4K的扇区组成。我们不会固定使用某个扇区。相反，我们维护一个“活动扇区”（Active Sector）的指针。所有新的数据写入，都只发生在这个活动扇区内。

当活动扇区被写满（或者接近写满）时，我们就启动一次“垃圾回收”流程：

从池中找出一个“空闲的”（已擦除的）扇区，作为新的活动扇区。
将旧活动扇区中的有效数据搬运到新的活动扇区。
擦除旧的活动扇区，使其变为“空闲扇区”，放回池中备用。

这样，写入的“磨损”就被依次轮询到了所有扇区上。这就是最基本的轮询式磨损均衡。

3.2 关键数据结构：如何标记数据与扇区状态

如何在Flash中组织数据，是算法的核心。我们不能像在RAM里那样用链表或复杂结构，因为Flash写入次数有限。这里介绍一种非常实用且 robust 的方案：“标签-长度-值”（Tag-Length-Value, TLV）格式 + 扇区头。

扇区头（Sector Header）：在每个扇区的起始位置（例如前16个字节），我们写入一个固定的数据结构，用来标识这个扇区的状态和元信息。这个头只在扇区被初始化为活动扇区时写入一次，直到扇区被擦除。

typedef struct { uint32_t sectorMagic; // 魔数，如0xABCD1234，用于识别这是一个有效的扇区头 uint16_t sectorSeqNum; // 扇区序列号，每次分配新活动扇区时递增 uint8_t sectorStatus; // 状态：FREE（0xFF）, ACTIVE（0xAA）, DIRTY（0x55）等 uint8_t reserved; // 保留 uint32_t writeOffset; // 该扇区内下一个可写入数据的偏移地址（相对于扇区起始） } FlashSectorHeader_t;

sectorSeqNum（序列号）是关键。它是一个单调递增的计数器（写入Flash）。当我们需要从多个扇区中找出“最新的”活动扇区时（比如系统复位后），只需要比较所有扇区的序列号，最大的那个就是最近使用的活动扇区。这比依赖时间戳更可靠，因为RTC可能没电或未初始化。
sectorStatus清晰地定义了扇区生命周期：FREE（已擦除，可用）、ACTIVE（当前正在写入）、DIRTY（已满，待回收）。
writeOffset指向扇区内空闲空间的开始位置，避免每次写入都要线性扫描。

数据项（Data Item）：在扇区头之后，我们按顺序存储一个个数据项。每个数据项也采用一个简单的头结构：

typedef struct { uint16_t dataTag; // 数据的标签或ID，例如0x0001代表“设备序列号”，0x0002代表“运行时间” uint16_t dataLen; // 数据的实际长度（字节） // 紧接着是 dataLen 字节的实际数据 // 最后可以跟一个CRC16校验码（可选，但强烈推荐） } FlashDataItemHeader_t;

当需要更新某个dataTag的数据时，我们从不去原地修改旧数据。我们只是在当前活动扇区的writeOffset处，写入一个全新的数据项（相同的dataTag，新的内容和长度）。旧的数据项依然物理存在于它原来的扇区里，只是它变成了“过时的”数据。

查找最新数据：当需要读取dataTag=0x0001的数据时，算法会从最新的活动扇区开始，反向扫描整个虚拟EEPROM池。找到的第一个dataTag为0x0001的数据项，就是当前有效的最新数据。这种“追加写 + 反向查找”的模式，天然避免了原地更新，是Flash友好型设计的基础。

3.3 完整的操作流程与状态迁移

让我们把上面的概念串起来，看一个完整的场景：

系统初始化：

遍历虚拟EEPROM池中的所有扇区。
读取每个扇区的SectorHeader。通过magic和CRC（如果加了）验证有效性。
找出sequenceNum最大的那个ACTIVE扇区，将其设置为当前activeSector。如果找不到ACTIVE扇区（例如第一次使用），则找一个FREE扇区，写入头信息，将其初始化为ACTIVE。
根据activeSector的writeOffset，确定下一个写入位置。

写入数据（WriteData）：

检查activeSector剩余空间是否足够放下新的数据项（头+数据+CRC）。
如果空间不足，则触发**扇区回收（Sector Reclaim）**流程。
如果空间足够，则在writeOffset处依次写入：dataTag,dataLen,data,CRC16。
更新内存中activeSector的writeOffset（注意：此时不立即回写Flash中的writeOffset，为了减少对头部的频繁写入。我们可以在内存中维护这个值，仅在扇区切换或特定时刻同步一次，或者干脆每次写入后都更新，取决于对可靠性和磨损的权衡）。

扇区回收（垃圾回收）流程：

从池中找到一个FREE扇区（如果找不到，说明池满了，这是一个错误状态，需要处理）。
将这个FREE扇区初始化为新的ACTIVE扇区：写入新的SectorHeader，其中sequenceNum为上一个sequenceNum+1，writeOffset指向头部之后。
数据迁移：遍历所有dataTag，对于每个唯一的dataTag，使用“反向查找”找到其最新的有效数据项，然后将其写入新的活动扇区。这一步确保了只有最新数据被保留，过时数据被丢弃。
将旧的活动扇区标记为DIRTY（可选，也可以直接擦除）。
擦除旧的DIRTY扇区，将其状态标记为FREE。
更新系统指针，指向新的活动扇区。

这个流程确保了：

磨损均衡：每次回收，都会换一个新的扇区进行写入，擦除旧的扇区。
数据一致性：在数据迁移完成、新扇区头写入成功之前，旧扇区依然保持完整可读。即使迁移过程中断电，最坏情况是丢失本次迁移，但旧数据完好无损。这需要仔细设计写入顺序，属于“掉电保护”的范畴，下文会细说。
高效读取：虽然写入是追加的，但读取时通过反向扫描，时间复杂度是O(N)，对于小型参数表（几十到几百个条目）来说，在单片机上是完全可接受的。

4. 实战代码剖析与避坑指南

理论说完了，我们来看代码实现中的关键点和那些手册上不会写的细节。这里以STM32 HAL库为例。

4.1 Flash解锁、擦除与写入的严格时序

首先，操作Flash必须遵循严格的步骤，任何顺序错误或中断干扰都可能导致操作失败甚至芯片锁死。

// 1. 解锁Flash HAL_FLASH_Unlock(); // 2. 清除所有错误标志（重要！） __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS); // 3. 擦除一个扇区 FLASH_EraseInitTypeDef EraseInitStruct; uint32_t SectorError = 0; EraseInitStruct.TypeErase = FLASH_TYPEERASE_PAGES; // 或FLASH_TYPEERASE_SECTORS，取决于型号 EraseInitStruct.Banks = FLASH_BANK_1; // 对于单Bank芯片 EraseInitStruct.PageAddress = TargetSectorStartAddress; // 要擦除的扇区起始地址 EraseInitStruct.NbPages = 1; // 擦除1个扇区 if (HAL_FLASHEx_Erase(&EraseInitStruct, &SectorError) != HAL_OK) { // 擦除失败处理，SectorError会指示是哪个扇区出错 HAL_FLASH_Lock(); return ERROR_FLASH_ERASE; } // 4. 写入数据（必须以字/半字为单位） uint64_t dataToWrite = ...; // 你的数据，注意对齐 uint32_t address = ...; // 目标地址，必须对齐到写入宽度（如字写入要对齐到4字节） for (int i = 0; i < dataLength; i += 8) { // 以双字(64位)为例，HAL库提供了双字编程接口，效率更高 if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, address, *(uint64_t*)(sourceData + i)) != HAL_OK) { // 写入失败处理 HAL_FLASH_Lock(); return ERROR_FLASH_PROGRAM; } address += 8; } // 5. 上锁 HAL_FLASH_Lock();

避坑点1：中断与看门狗Flash擦写操作耗时很长（擦除一个4K扇区可能需要几十ms）。在此期间必须禁止所有中断（包括SysTick），并且暂停独立看门狗（IWDG）。否则，中断服务程序或看门狗复位可能会打断Flash操作，导致Flash控制器状态错误，甚至硬件故障。

__disable_irq(); // 禁止总中断 // ... 执行Flash擦写操作 ... __enable_irq(); // 重新开启中断

对于看门狗，如果是窗口看门狗（WWDG），操作期间无法喂狗，所以设计时要确保Flash操作时间小于看门狗超时时间。对于独立看门狗（IWDG），通常可以在操作前将其暂停（如果芯片支持），或者使用更长的超时时间。

避坑点2：擦除后的状态验证不要认为HAL_FLASHEx_Erase返回HAL_OK就万事大吉。擦除完成后，务必读取整个扇区的数据，验证是否全部变为0xFF。我遇到过芯片本身Flash有微小坏块（出厂瑕疵）的情况，擦除指令成功，但某个地址永远擦不干净，导致后续写入异常。增加验证步骤能及早发现问题。

4.2 数据一致性设计与掉电保护

这是工业级产品必须考虑的问题。假设系统正在执行扇区回收流程的第3步（数据迁移），突然断电了。上电后，我们可能面临：

新扇区头写了部分，数据没开始迁移。
新扇区数据迁移了一半。
新扇区数据迁移完了，但旧扇区还没标记为DIRTY或擦除。

我们的算法必须能从容应对这些中间状态，保证至少有一份完整、一致的数据可用。这通常通过原子操作和状态标志来实现。

方案：双状态位与顺序写入

在扇区头中，我们设计两个状态位：MainStatus和CopyStatus。
开始迁移前：在新扇区写入一个临时的头，MainStatus = COPYING，CopyStatus = INVALID。此时新扇区尚未生效。
迁移数据：将有效数据项逐个写入新扇区。
数据迁移完成：关键一步，将新扇区头的MainStatus更新为ACTIVE。这个更新必须是一个单独的Flash写入操作（例如，只改写状态字）。只有这一步成功了，新扇区才被视为有效。
清理旧扇区：将旧扇区标记为DIRTY，然后擦除。

上电恢复逻辑：

扫描所有扇区，寻找MainStatus == ACTIVE的扇区。这就是当前有效扇区。
如果找到多个ACTIVE扇区（异常），选择sequenceNum最大的。
如果发现一个MainStatus == COPYING的扇区，说明上次迁移未完成。这个扇区的内容是不完整且不可信的，应直接将其擦除，回退到sequenceNum次大的ACTIVE扇区（即上一次的稳定状态）。

通过这种设计，我们确保了无论在任何步骤断电，系统总能回退到一个完整的数据版本。数据可能不是最新的（丢失了最后一次写入），但绝不会错乱。

4.3 空间优化与寿命计算实例

假设我们使用4个4K扇区（共16K）作为虚拟EEPROM。

每个扇区头占用16字节。
每个数据项头占用4字节（tag2字节 +len2字节），如果加CRC16，则再占2字节。
我们想存储20个不同的参数，每个参数平均长度10字节。

计算管理开销：

扇区头总开销：4扇区 * 16字节 = 64字节。
数据项头开销：每次写入一个参数，至少产生4字节头。假设CRC不加在Flash里，而是运行时计算校验（更省空间但安全性稍低）。
有效数据空间：16K - 64字节 ≈ 16320字节。

估算寿命：

每个参数更新一次，会在当前活动扇区写入一个4字节头 + 10字节数据 = 14字节的新条目。
当一个扇区写满（4K - 16字节头 ≈ 4080字节可用）时，能容纳4080 / 14 ≈ 291次参数更新。
然后触发垃圾回收，磨损转移到下一个扇区。
4个扇区轮询一遍，总共可进行291 * 4 ≈ 1164次全参数更新（即所有20个参数各更新一次）。
单个扇区寿命1万次，总擦写次数为4 * 10,000 = 40,000次。
但我们的算法下，每1164次全参数更新，才会让每个扇区各被擦写一次。因此，这个虚拟EEPROM池的理论总更新次数为：40,000 * 1164 ≈ 46,560,000次。
如果平均每秒更新1个参数，那么总寿命可达539天。这相比于固定扇区方案的2.78小时，是质的飞跃。

这个计算表明，磨损均衡算法通过空间换时间，将Flash的有限擦写寿命放大了数个数量级，足以满足绝大多数嵌入式应用的需求。

5. 进阶优化与问题排查

5.1 减少写放大（Write Amplification）

写放大是Flash存储中的一个重要概念，指实际写入Flash的物理数据量大于逻辑上需要更新的数据量。我们的TLV格式+追加写，天然存在写放大：每次更新一个参数，都要写入整个新数据项，而不是只修改变化的部分。为了优化：

数据打包：将多个关联性强、经常同时更新的小参数打包成一个大的数据项写入。例如，将“年-月-日-时-分-秒”打包成一个6字节的时间戳项，而不是分成6个独立的1字节项。这样，更新一次时间，只写入一个数据项（头+6字节），而不是6个数据项（6个头+6字节）。
延迟写入：在RAM中缓存频繁更新的数据，定期（例如每10秒、每分钟）或满足一定条件（缓存数据达到一定量）时，再一次性写入Flash。这能显著减少Flash写入次数。但要注意掉电风险，关键数据可能因此丢失，需要根据应用权衡。

5.2 处理坏块与ECC

虽然STM32内部Flash出厂坏块率极低，但长期频繁擦写后，仍有可能出现“弱位”或“坏块”。对于可靠性要求极高的应用，可以考虑：

预留空间：不将全部扇区都用于活跃存储，而是预留1-2个扇区作为备用。当检测到某个扇区擦写失败或验证失败时，将其标记为坏块，用备用扇区顶替。这需要更复杂的管理逻辑。
启用硬件ECC：部分高端STM32系列（如H7）的Flash支持硬件ECC（纠错码）。开启后，Flash控制器能自动检测和纠正单位错误，检测双位错误，大大提升了数据可靠性。如果你的芯片支持，强烈建议在CubeMX中启用此功能。

5.3 调试技巧与常见问题排查

问题：数据读取错误，校验和不通过。
- 排查步骤：
  1. 检查地址对齐：确保所有Flash写入操作的地址都符合对齐要求（半字、字、双字）。不对齐的写入是未定义行为，可能导致写入失败或读出错误数据。使用assert((address % 4) == 0)之类的断言。
  2. 验证擦除状态：在写入前，读取目标地址及其周围几个字，确认都是0xFFFFFFFF。如果不是，说明之前的擦除操作未完成或该区域不是可写状态。
  3. 检查中断：在Flash操作期间，是否有中断发生？用逻辑分析仪或调试器设置断点，检查__disable_irq()和__enable_irq()是否包裹了整个擦写过程。
  4. 检查电源：Flash编程对电源电压非常敏感。在电池供电设备中，确保在Flash操作时电压处于芯片规定的工作范围之内。可以在操作前读取芯片的电源状态寄存器（PWR）或ADC检测电压。
  5. 逐步缩小范围：写一个最简单的测试函数，只反复擦写一个固定地址，写入一个固定值（如0xA5A5A5A5），然后读出验证。如果这个简单测试都失败，问题很可能在底层驱动、时钟配置或硬件上。
问题：磨损均衡算法运行一段时间后，找不到有效数据了。
- 排查步骤：
  1. 打印扇区状态：在初始化时，将每个扇区的magic、sequenceNum、status、writeOffset通过串口打印出来。观察状态迁移是否符合预期。
  2. 检查序列号溢出：sequenceNum是16位还是32位？如果使用16位，在极端频繁的擦写下（虽然很难），可能会溢出归零。建议使用32位，或者实现一个溢出处理机制（例如，当检测到所有扇区序列号都很大且接近溢出时，执行一次“整理”操作，将所有有效数据迁移到一个新池，并将序列号重置）。
  3. 检查垃圾回收触发条件：是“写满”触发还是“空间不足”触发？如果你的writeOffset计算有误，可能导致扇区还未满就误触发回收，或者满了却不触发导致写入失败。确保writeOffset的管理是原子且准确的。
  4. 检查数据项CRC：为每个数据项增加CRC校验。在读取时校验，如果CRC错误，则跳过该数据项。这能防止因Flash位翻转导致的错误数据被误认为是有效的。

实现一个稳定可靠的Flash模拟EEPROM磨损均衡算法，是对嵌入式开发者基本功的一次综合考验。它涉及到底层硬件操作、数据结构设计、状态机管理、异常处理和系统可靠性设计。当你成功地将它应用到产品中，并稳定运行数年之后，你会对“嵌入式存储”有更深的理解。这套方案不仅适用于STM32，其核心思想也可以移植到其他带有内部Flash的MCU平台上。最关键的是，它帮助你在不增加一分钱硬件成本的情况下，为产品赢得了关键的数据可靠性，这正是嵌入式软件价值的体现。

查看全文

http://www.jsqmd.com/news/1285501/