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 物理结构的根本区别EEPROMElectrically 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盘的FTLFlash 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; // 状态FREE0xFF, ACTIVE0xAA, DIRTY0x55等 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新的内容和长度。旧的数据项依然物理存在于它原来的扇区里只是它变成了“过时的”数据。查找最新数据当需要读取dataTag0x0001的数据时算法会从最新的活动扇区开始反向扫描整个虚拟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为上一个sequenceNum1writeOffset指向头部之后。数据迁移遍历所有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 COPYINGCopyStatus 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 调试技巧与常见问题排查问题数据读取错误校验和不通过。排查步骤检查地址对齐确保所有Flash写入操作的地址都符合对齐要求半字、字、双字。不对齐的写入是未定义行为可能导致写入失败或读出错误数据。使用assert((address % 4) 0)之类的断言。验证擦除状态在写入前读取目标地址及其周围几个字确认都是0xFFFFFFFF。如果不是说明之前的擦除操作未完成或该区域不是可写状态。检查中断在Flash操作期间是否有中断发生用逻辑分析仪或调试器设置断点检查__disable_irq()和__enable_irq()是否包裹了整个擦写过程。检查电源Flash编程对电源电压非常敏感。在电池供电设备中确保在Flash操作时电压处于芯片规定的工作范围之内。可以在操作前读取芯片的电源状态寄存器PWR或ADC检测电压。逐步缩小范围写一个最简单的测试函数只反复擦写一个固定地址写入一个固定值如0xA5A5A5A5然后读出验证。如果这个简单测试都失败问题很可能在底层驱动、时钟配置或硬件上。问题磨损均衡算法运行一段时间后找不到有效数据了。排查步骤打印扇区状态在初始化时将每个扇区的magic、sequenceNum、status、writeOffset通过串口打印出来。观察状态迁移是否符合预期。检查序列号溢出sequenceNum是16位还是32位如果使用16位在极端频繁的擦写下虽然很难可能会溢出归零。建议使用32位或者实现一个溢出处理机制例如当检测到所有扇区序列号都很大且接近溢出时执行一次“整理”操作将所有有效数据迁移到一个新池并将序列号重置。检查垃圾回收触发条件是“写满”触发还是“空间不足”触发如果你的writeOffset计算有误可能导致扇区还未满就误触发回收或者满了却不触发导致写入失败。确保writeOffset的管理是原子且准确的。检查数据项CRC为每个数据项增加CRC校验。在读取时校验如果CRC错误则跳过该数据项。这能防止因Flash位翻转导致的错误数据被误认为是有效的。实现一个稳定可靠的Flash模拟EEPROM磨损均衡算法是对嵌入式开发者基本功的一次综合考验。它涉及到底层硬件操作、数据结构设计、状态机管理、异常处理和系统可靠性设计。当你成功地将它应用到产品中并稳定运行数年之后你会对“嵌入式存储”有更深的理解。这套方案不仅适用于STM32其核心思想也可以移植到其他带有内部Flash的MCU平台上。最关键的是它帮助你在不增加一分钱硬件成本的情况下为产品赢得了关键的数据可靠性这正是嵌入式软件价值的体现。