GD32F303内部Flash模拟EEPROM：磨损均衡与掉电保护实战

1. 项目缘起：为什么要在GD32F303上用内部Flash替代EEPROM

做嵌入式开发的朋友大概率都遇到过这个场景：板子上需要保存几个关键参数，比如设备序列号、校准系数、用户配置项，掉电之后不能丢。第一反应往往是外挂一颗EEPROM，比如AT24C02、AT24C16这类I2C接口的小芯片。但真到了量产阶段，问题就来了——BOM成本增加、PCB面积被占、采购周期不稳定、焊接良率多一个风险点。尤其是那种成本敏感、空间紧凑的小型工控板或者消费类设备，多一颗芯片就是多一份麻烦。

GD32F303这颗MCU我自己用得很顺手，Cortex-M4内核，主频能跑到120MHz，外设资源也够丰富。它内部有最高512KB的Flash，实际项目里代码往往用不到一半，剩下的空间完全可以拿来当数据存储区。用内部Flash模拟EEPROM，省掉外挂芯片，硬件成本直接降下来，而且读写速度比I2C的EEPROM快得多——I2C那点速率，写一个字节要等好几个毫秒，内部Flash虽然也要等擦除，但整体吞吐量完全不是一个量级。

不过这里有个坑必须提前说清楚：Flash的擦写寿命和EEPROM没法比。EEPROM按字节擦写，典型寿命100万次；GD32F303的内部Flash擦写寿命官方手册标的是10万次，而且是按扇区擦除。如果你频繁写同一个地址，比如每秒存一次数据，那这个扇区很快就废了。所以这个项目的核心不只是“怎么把数据写进Flash”，更重要的是“怎么让Flash活得久一点”，也就是磨损均衡。

这篇文章适合谁看？如果你正在用GD32F303做项目，需要掉电保存功能，又不想加外挂EEPROM，那这篇内容可以直接抄作业。我会从Flash的物理特性讲起，把扇区划分、读写接口、磨损均衡算法、掉电保护策略全部拆开，最后给出一套可以直接移植的代码框架。即使你用的是GD32其他系列或者STM32，思路也是通用的。

2. 先搞懂GD32F303内部Flash的脾气

2.1 Flash和EEPROM的本质区别

很多人把Flash和EEPROM混着叫，其实两者在物理结构上差别很大。EEPROM是电可擦除可编程只读存储器，它可以在字节级别直接修改数据，写之前不需要擦除，硬件内部自动处理。Flash则是按块组织的，写之前必须先擦除整个扇区，擦除后所有位变成1，写入操作只能把1变成0，不能把0变回1。这个特性决定了Flash的写入逻辑和EEPROM完全不同。

GD32F303的Flash控制器支持页擦除和整片擦除，页大小根据型号不同有2KB和4KB两种。以GD32F303ZE为例，512KB的Flash分成若干页，每页2KB。擦除一页的时间大概是20到40毫秒，写入一个字（32位）大概几十微秒。这个时间在掉电保存场景下是可以接受的，因为掉电保存通常只在检测到掉电信号或者主动保存时触发，不是每时每刻都在写。

注意：Flash擦除期间CPU如果从同一块Flash取指令，会出现总线阻塞。所以擦写操作最好放在RAM中执行，或者确保擦写期间不执行同块Flash的代码。GD32的固件库已经帮我们处理了这个问题，但如果你自己写底层驱动，这一点必须留意。

2.2 扇区划分与地址映射

GD32F303的Flash起始地址是0x08000000，这是代码区的起点。假设你的程序编译出来占用了前128KB，那从0x08020000开始就可以拿来做数据存储。我一般习惯把最后几个扇区留给数据区，这样代码区扩容的时候不会冲突。

具体划分方案要看你的数据量和磨损均衡策略。如果只是存几十个字节的配置参数，用一个2KB的扇区就够了。但为了磨损均衡，通常需要至少两个扇区交替使用。我的建议是划出4个扇区，每个2KB，总共8KB，对于大多数应用来说绰绰有余。

地址计算很简单：扇区n的起始地址 = 0x08000000 + n × 2048。比如第100个扇区，起始地址就是0x08000000 + 100 × 2048 = 0x08032000。在代码里用宏定义把这些地址管理起来，后面改起来方便。

2.3 擦写寿命与磨损均衡的必要性

前面提到GD32F303的Flash擦写寿命是10万次。这个数字看起来不小，但你要这么想：如果一个扇区每天擦写100次，1000天就用完了，不到三年。如果是工业设备，设计寿命动辄十年，那肯定不够。而且这10万次是理想条件下的标称值，实际使用中温度、电压波动都会影响寿命。

磨损均衡的核心思想就是不要让擦写操作集中在同一个物理地址上。最简单的做法是准备两个扇区，轮流写。写满一个扇区后，把有效数据搬到另一个扇区，然后擦除旧扇区。这样每个扇区的擦写次数就减半了。如果再加入地址映射表，把逻辑地址动态映射到物理地址，磨损就能更均匀地分布到整个数据区。

我实测过一个方案：用4个扇区做环形缓冲，每个扇区分成若干条记录，每条记录包含数据、校验和、写入序号。写的时候顺序往后追加，写满一个扇区就跳到下一个。擦除操作只在扇区写满后才发生。这样在数据量不大的情况下，擦除频率极低，Flash寿命轻松超过设备本身的设计寿命。

3. 整体方案设计：从需求到架构

3.1 需求拆解与设计目标

在动手写代码之前，先把需求理清楚。掉电保存功能的核心需求有这么几条：第一，数据写入后能可靠保存，掉电不丢；第二，写入次数要尽可能少，延长Flash寿命；第三，掉电瞬间要有保护机制，不能写到一半断电导致数据损坏；第四，读取速度要快，不能影响系统实时性；第五，代码要可移植，方便换到其他项目。

基于这些需求，我设计的方案包含三个层次：底层是Flash驱动层，负责扇区擦除、数据写入、数据读取；中间是存储管理层，负责地址映射、磨损均衡、掉电保护；上层是应用接口层，提供类似EEPROM的按地址读写接口。这样分层的好处是，底层驱动可以复用GD32的固件库，存储管理逻辑可以独立测试，应用层调用简单。

3.2 为什么选择双扇区交替加日志式写入

磨损均衡算法有很多种，最简单的就是双扇区交替：两个扇区，一个当前使用，一个备用。写满当前扇区后，把有效数据复制到备用扇区，擦除当前扇区，然后交换角色。这个方案实现简单，可靠性高，但磨损还是集中在两个扇区上。

更进一步的是日志式写入，也叫追加写入。每个扇区被分成多个记录槽，每次写入数据时，不是覆盖旧数据，而是在扇区末尾追加一条新记录。记录里包含逻辑地址、数据长度、数据和校验值。读取的时候从后往前扫描，找到每个逻辑地址最新的记录。当扇区写满后，把每个逻辑地址的最新记录整理出来，写到下一个扇区，然后擦除旧扇区。

这个方案的好处很明显：擦除操作只在扇区写满后发生，写入操作只是简单的追加，不需要擦除。假设每个记录占16字节，一个2KB的扇区能存128条记录。如果你每天写10次，那12.8天才需要擦除一次。10万次擦写寿命，算下来能用3500多年。当然这是理论值，实际还要考虑其他因素，但足以说明问题。

我最终选择的是日志式写入加多扇区环形管理。用4个扇区组成一个环形队列，写满一个就切到下一个，同时触发垃圾回收。这样磨损分布到4个扇区上，寿命再翻4倍。

3.3 掉电保护策略设计

掉电保护是这个项目的难点。你想想，如果正在写Flash的时候突然断电，会是什么后果？如果只是追加写入，最坏情况是最后一条记录写了一半，校验不过，读取的时候跳过这条就行，之前的数据不受影响。但如果是擦除过程中断电，那整个扇区的数据就全没了。

所以掉电保护的核心原则是：永远不要擦除唯一一份有效数据。我的做法是，在擦除一个扇区之前，确保下一个扇区的数据已经完整写入并校验通过。具体流程是：当前扇区写满后，先把所有有效数据整理写入下一个扇区，校验通过后，再擦除当前扇区。这样即使擦除过程中断电，下一个扇区还有完整数据，系统重启后能正常恢复。

另外，在写入每条记录时，先写数据，再写校验和，最后写状态标志。状态标志用一个特定的魔数表示“这条记录有效”。读取的时候先检查状态标志，再校验数据。如果状态标志不对或者校验失败，就认为这条记录无效，跳过。这样即使写到一半断电，也不会影响已有数据。

提示：GD32F303有内置的电压监测功能，可以配置低电压检测中断。在检测到电压低于阈值时，立即触发紧急保存，把关键数据写入Flash。这个功能配合掉电保护逻辑，能大幅提高可靠性。

4. 核心细节解析：Flash读写与磨损均衡实现

4.1 Flash解锁与擦除操作

GD32F303的Flash控制器默认是锁定的，防止误操作。要写Flash，先要解锁。解锁流程是：调用fmc_unlock()函数，这个函数会依次写入两个特定的密钥到FMC_KEY寄存器。解锁之后才能操作FMC_CTL寄存器进行擦除和编程。

擦除一个页的代码大概长这样：

fmc_state_enum flash_erase_page(uint32_t page_addr) { fmc_state_enum state; fmc_unlock(); fmc_flag_clear(FMC_FLAG_END | FMC_FLAG_WPERR | FMC_FLAG_PGERR); state = fmc_page_erase(page_addr); fmc_lock(); return state; }

这里有几个细节要注意。第一，擦除之前要清除所有标志位，否则可能会误判操作结果。第二，擦除完成后要重新锁定Flash，防止其他代码意外修改。第三，fmc_page_erase的返回值要检查，只有返回FMC_READY才表示擦除成功。

擦除时间大概20到40毫秒，这段时间CPU会暂停。如果你的系统有实时性要求，最好在擦除前关掉中断，擦除完成后再打开。或者把擦除操作放在系统空闲时执行。

4.2 数据写入与校验

Flash写入不像EEPROM那样可以按字节写，GD32F303支持按字（32位）、半字（16位）写入。我一般用按字写入，效率高。写入函数如下：

fmc_state_enum flash_write_word(uint32_t addr, uint32_t data) { fmc_state_enum state; fmc_unlock(); fmc_flag_clear(FMC_FLAG_END | FMC_FLAG_WPERR | FMC_FLAG_PGERR); state = fmc_word_program(addr, data); fmc_lock(); return state; }

写入之前要确保目标地址已经被擦除，也就是内容是0xFFFFFFFF。如果没擦除就写，写入的数据会是旧数据和新数据的按位与结果，肯定不对。

校验是保证数据可靠性的关键。我通常用CRC32或者简单的累加和。CRC32计算量大一点，但检错能力强。累加和实现简单，对于短数据够用。校验值要跟数据一起写入Flash，读取的时候重新计算并比对。

4.3 日志式记录结构设计

每条记录的结构我设计成固定16字节，方便地址计算：

这个结构支持每次写4字节数据，对于大多数配置参数够用了。如果要存更长的数据，可以扩展数据字段，或者用多条记录拼起来。

写入流程是：先找到当前扇区的下一个空槽，计算地址，然后依次写入状态标志、逻辑地址、数据长度、数据、校验和。注意写入顺序，状态标志最后写，这样即使前面写完了但状态标志没写，读取的时候也会认为这条记录无效。

4.4 磨损均衡算法实现

磨损均衡的核心逻辑在写入和垃圾回收两个环节。写入的时候，不是直接覆盖旧数据，而是追加新记录。读取的时候，从扇区末尾往前扫描，找到每个逻辑地址最新的有效记录。

垃圾回收的触发条件是当前扇区剩余空间不足。回收流程是：遍历当前扇区所有有效记录，把每个逻辑地址的最新值整理出来，写入下一个扇区。写入完成后，校验下一个扇区的数据，确认无误后擦除当前扇区，把当前扇区标记为空闲。

这里有个细节：整理数据的时候，同一个逻辑地址可能有多条记录，只需要保留最新的那条。怎么判断最新？记录里可以加一个写入序号，或者利用记录在扇区中的位置——越靠后的记录越新。我用的是位置判断，因为追加写入天然保证了顺序。

扇区状态用一个单独的标志位来管理。每个扇区的第一个字用来存状态：0xFFFFFFFF表示空闲，0x00000000表示正在使用，0xAAAAAAAA表示已满待回收。系统启动时扫描所有扇区，找到正在使用的那个，然后从里面恢复数据。

5. 实操过程：从零搭建断电保存模块

5.1 工程配置与Flash空间规划

先在Keil或者IAR里新建一个GD32F303的工程，配置好时钟和基本外设。然后打开链接脚本或者分散加载文件，把数据区预留出来。以Keil为例，在Target选项卡里修改ROM的起始地址和大小，把最后8KB排除掉。比如512KB的Flash，ROM配置成0x08000000开始，大小0x7E000，这样最后8KB就不会被代码占用。

接着定义数据区的宏：

#define DATA_FLASH_START 0x0807E000 #define DATA_FLASH_END 0x08080000 #define DATA_SECTOR_SIZE 2048 #define DATA_SECTOR_COUNT 4 #define DATA_SECTOR_ADDR(n) (DATA_FLASH_START + (n) * DATA_SECTOR_SIZE)

这些宏后面会频繁用到，定义清楚能避免很多地址计算错误。

5.2 底层驱动编写与测试

底层驱动包含三个函数：擦除扇区、写入数据、读取数据。擦除和写入直接调用GD32固件库的fmc_page_erase和fmc_word_program。读取更简单，直接用指针访问：

uint32_t flash_read_word(uint32_t addr) { return *(volatile uint32_t *)addr; }

写完驱动后先做个简单测试：擦除一个扇区，写入几个字，然后读出来比对。再擦除，再写入，反复几次，确认稳定。这个测试能帮你排除大部分硬件和配置问题。

注意：调试的时候如果开了Flash断点，可能会影响擦写操作。建议在RAM里调试，或者把断点设在擦写之后。

5.3 存储管理层实现

存储管理层的核心是一个结构体，记录当前扇区号、当前写入偏移、以及一个内存缓存。内存缓存用来加速读取，避免每次都去扫描Flash。

typedef struct { uint8_t sector_index; uint16_t write_offset; uint8_t cache[256]; uint8_t cache_valid; } storage_ctx_t;

初始化的时候，扫描所有扇区，找到正在使用的扇区，然后把有效数据加载到缓存。加载过程就是从扇区开头往后扫描，遇到有效记录就更新缓存中对应逻辑地址的值。

写入的时候，先更新缓存，然后在当前扇区追加一条记录。如果扇区剩余空间不足，触发垃圾回收。垃圾回收就是把缓存中的数据完整写入下一个扇区，然后擦除当前扇区。

5.4 掉电检测与紧急保存

GD32F303的电源管理单元支持低电压检测。配置好之后，当电压低于设定阈值时，会触发中断。在中断服务函数里，立即调用存储层的保存函数，把缓存中的数据写入Flash。

这里要注意，中断服务函数里不能做太耗时的操作。如果数据量不大，直接写一条记录就行。如果数据量大，可以只保存最关键的几个参数，其他参数等下次正常保存。

另外，掉电检测的阈值要设置合理。太低的话，还没来得及写完就没电了；太高的话，正常电压波动就会误触发。一般设置在2.7V到2.9V之间比较合适，具体要看你的电源设计。

6. 常见问题与排查技巧实录

6.1 写入失败或数据错乱

最常见的问题是写入地址没有对齐。GD32F303的Flash编程要求地址按字对齐，也就是地址必须是4的倍数。如果你传了一个非对齐的地址，写入会失败或者写入错误的数据。解决办法是在写入函数里加一个地址对齐检查，不对齐就返回错误。

另一个常见问题是擦除不彻底。有时候擦除操作返回成功，但实际内容没完全变成0xFF。这通常是因为擦除期间有中断打断了操作。解决办法是在擦除前关中断，擦除后开中断。

6.2 读取数据全FF或全00

读取全FF说明扇区是空的，没有有效记录。检查一下初始化流程，是不是没有正确扫描扇区。读取全00说明扇区被擦除了但状态标志没更新，或者读取地址算错了。用调试器直接查看Flash内容，确认地址和数据是否正确。

还有一种可能是编译器优化导致的。volatile关键字一定要加，否则编译器可能把读取操作优化掉，读到的是缓存里的旧值。

6.3 磨损均衡不生效

如果发现擦除操作还是集中在同一个扇区，检查垃圾回收的触发条件。可能是扇区剩余空间判断有误，或者扇区切换逻辑没写对。在垃圾回收函数里加打印，观察每次回收时扇区号的变化。

另外，如果数据量很小但写入频率很高，比如每秒写一次，那即使有磨损均衡，擦除频率还是很高。这种情况下可以考虑在RAM里做缓存，积累一定数量的修改后再统一写入Flash。

6.4 掉电后数据丢失

掉电丢失通常是因为保存时机不对。如果你是在检测到掉电后才开始写，那留给你的时间窗口很短。电容上的储能有限，可能只够写几条记录。解决办法是提前保存，比如在数据修改后就立即写入，而不是等掉电再写。

还有一种可能是掉电检测阈值设置不当。用示波器观察电源电压和掉电中断的触发时刻，调整阈值电阻分压比，确保有足够的写入时间。

6.5 常见问题速查表

7. 进阶优化：让方案更稳更耐用

7.1 增加ECC校验与坏块管理

如果对可靠性要求极高，可以在每条记录里加ECC校验。简单的汉明码能纠正一位错误，检测两位错误。实现起来不复杂，但能大幅提高数据可靠性。坏块管理则是记录哪些扇区已经擦写次数过多，提前标记为不可用，避免写到坏块导致数据丢失。

7.2 多级缓存减少Flash写入

在RAM里做一个多级缓存，把频繁修改的数据暂存在缓存里，积累到一定量或者定时触发时才写入Flash。这样能大幅减少Flash写入次数。比如一个计数器每秒加一，如果每次都写Flash，一天就是86400次；如果每分钟写一次，一天只有1440次，寿命延长60倍。

7.3 数据压缩与去重

如果存储的数据有很多重复或者规律性，可以在写入前做压缩。简单的RLE压缩或者差分编码就能减少数据量，从而减少占用的记录槽，间接延长Flash寿命。去重则是把相同的数据合并，只保留一份。

7.4 移植到其他GD32系列

这套方案的思路是通用的，移植到GD32F103、GD32F407等其他系列只需要改几个地方：Flash起始地址、扇区大小、固件库函数名。存储管理层和应用接口层完全不用动。我试过从F303移植到F407，半天就搞定了。

8. 个人实操心得与踩坑记录

这个方案我在三个项目里实际用过，最长的已经稳定运行两年多，没有出现过数据丢失。踩过的坑也不少，说几个印象深刻的。

第一个坑是扇区状态标志的设计。一开始我用0xFFFFFFFF表示空闲，0x00000000表示使用中，结果发现擦除后扇区内容就是0xFFFFFFFF，跟空闲状态冲突了。后来改成用不同的魔数区分，比如0xA5A5A5A5表示使用中，0x5A5A5A5A表示已满，0xFFFFFFFF表示空闲，问题就解决了。

第二个坑是垃圾回收时的数据一致性。有一次回收过程中断电，重启后发现数据丢了。原因是回收时先擦除了旧扇区，但新扇区的数据还没写完。后来改成先写新扇区，校验通过后再擦旧扇区，就再没出过问题。

第三个坑是掉电检测的响应时间。一开始阈值设得太低，掉电中断触发时电压已经降到2.5V以下，Flash写入不稳定。后来把阈值调到2.9V，并且加大了电源滤波电容，给写入留出了足够的时间。

最后分享一个小技巧：在Flash数据区的开头放一个版本号，每次修改存储结构时递增。系统启动时检查版本号，如果不匹配就执行数据迁移或者恢复默认值。这样后续升级固件时，不会因为存储结构变化导致数据错乱。

这套方案的核心思想其实就一句话：用追加写入代替覆盖写入，用空间换寿命。理解了这一点，具体的代码实现都是水到渠成的事。