华大HC32F460：巧用Flash模拟EEPROM实现安全数据存储
1. 为什么需要Flash模拟EEPROM
在嵌入式系统开发中，数据存储是个永恒的话题。就拿我最近做的智能温湿度传感器项目来说，设备需要记录环境参数的历史数据，还要保存用户设置的报警阈值。这些数据在断电后必须保留，否则每次重启设备都要重新配置，用户体验就太糟糕了。
传统方案是外挂EEPROM芯片，比如24C02这类I2C接口的存储器件。但实际用下来发现几个痛点：首先占用了宝贵的PCB面积，现在很多物联网设备都追求小型化；其次增加了BOM成本，别看一颗EEPROM只要几毛钱，量产后也是笔不小开支；最重要的是增加了电路复杂度，I2C总线上还要考虑上拉电阻、信号完整性问题。
华大HC32F460这颗MCU内置512KB Flash，实际项目中发现程序空间根本用不完。于是我就琢磨：能不能划出一小块Flash来当EEPROM用？实测下来这个方案确实香，省去了外挂芯片，设计复杂度直线下降。但Flash和EEPROM在物理特性上有本质区别，直接照搬EEPROM的用法会踩坑。
2. Flash与EEPROM的关键差异
2.1 物理特性对比
先看个实际测试案例：我用STM32的Flash存储一组参数，上电读取时偶尔会出现数据异常。后来用逻辑分析仪抓取波形才发现，在频繁写操作期间读取Flash，确实会出现数据紊乱。这与华大芯片手册里"擦写期间读取值不确定"的警告完全吻合。
对比两者的关键参数：
| 特性 | Flash | EEPROM |
|---|---|---|
| 擦除单位 | 8KB扇区 | 单字节 |
| 写入单位 | 4字节 | 单字节 |
| 擦写寿命 | 约1万次 | 10万次以上 |
| 读取干扰 | 擦写时不可读 | 随时可读 |
| 功耗 | 擦写电流大 | 功耗平稳 |
2.2 工程化挑战
基于这些差异，在设计Flash模拟方案时要解决三个核心问题：
- 擦除粒度大：改一个字节就要擦除整个8KB扇区
- 操作不可中断：擦写过程中断电会导致数据丢失
- 执行安全：擦写期间不能执行Flash中的代码
我在早期版本中吃过亏：某次设备异常重启后，发现参数全部清零。后来用示波器捕捉电源波形才发现，正好在擦除扇区时断电了。这就是为什么需要双扇区备份机制——一个扇区擦写时，另一个始终保留完整数据。
3. 实战双扇区存储方案
3.1 存储结构设计
以16KB空间为例（两个8KB扇区），我的具体实现如下：
#define SECTOR_SIZE 8192 #define DATA_SIZE 256 // 单条记录大小 #define RECORDS_PER_SEC (SECTOR_SIZE/DATA_SIZE) typedef struct { uint32_t magic; // 标识符 0x55AA5AA5 uint32_t seq; // 序列号 uint16_t crc; // 数据校验 uint8_t data[246]; // 实际数据 } FlashRecord;存储策略采用环形缓冲：
- 首次写入地址0x08010000（扇区1起始+256偏移）
- 下次写入0x08010100，依此类推直到扇区满
- 切换至扇区2时，先擦除扇区1再继续写入
- 读取时选择序列号最大的有效记录
3.2 RAM运行关键代码
华大提供的EFM驱动库需要改造，以下是关键步骤：
- 修改hc32f460_efm.c文件，添加RAM代码段声明：
#pragma arm section code = ".RAM_CODE" void EFM_EraseSector(uint32_t u32SectorAddr) { // 原有擦除逻辑 } #pragma arm section code- scatter文件配置（重点注意加载域与执行域分离）：
RW_IRAM1 0x1FFF8000 0x0002F000 { *(.RAM_CODE) // 关键代码段 .ANY (+RW +ZI) }- 擦写操作标准流程：
__disable_irq(); memcpy(ram_func, Flash_Write, func_size); // 拷贝到RAM ram_func(params); // RAM执行 __enable_irq();实测发现，如果不关中断，在擦写期间触发中断会导致HardFault。这是因为中断向量表也在Flash中，此时无法正常读取。
4. 数据可靠性保障机制
4.1 异常掉电防护
通过三重保障确保数据安全：
- 写前校验：每次写入前检查目标地址是否已擦除
- 双副本存储：总是保持一个完整的数据副本
- 原子操作：先写新数据再擦旧扇区
我曾模拟各种异常场景进行测试：
- 写入过程中断电 → 通过CRC校验识别无效数据
- 擦除过程中断电 → 另一个扇区数据完好
- 数据错位写入 → 通过magic number过滤
4.2 磨损均衡优化
虽然Flash有1万次擦写寿命，但频繁更新同一区域还是会提前失效。我的优化策略：
- 动态偏移写入：不在固定地址重复写入
- 脏块标记：记录每个块的擦写次数
- 自动整理：空闲时整理碎片数据
具体实现可以添加磨损计数：
typedef struct { uint32_t erase_count[2]; // 每个扇区擦除次数 uint32_t last_clean; // 上次整理时间戳 } WearLevelInfo;5. 性能优化技巧
5.1 加速读取方案
频繁读取Flash会影响性能，可以引入缓存机制：
- 启动时加载有效数据到RAM
- 采用LRU缓存最近访问记录
- 异步预取下条可能访问的数据
实测对比：
| 方案 | 平均读取时间 | 功耗增加 |
|---|---|---|
| 直接读Flash | 28us | 0% |
| RAM缓存 | 1.2us | 2% |
| 预取+缓存 | 0.8us | 5% |
5.2 批量写入优化
对于需要记录日志的场景，建议：
- 积累多条记录一次性写入
- 采用差分更新代替全量写入
- 使用更紧凑的数据格式
例如温度记录可以这样编码：
#pragma pack(1) typedef struct { uint16_t timestamp; // 分钟级时间戳 int8_t temp; // 精度0.5℃ uint8_t humi; // 精度0.5% } EnvLog;6. 实际项目中的坑与经验
第一个量产项目用了这个方案后，现场有约0.1%的设备出现数据异常。经过三个月排查才发现问题根源：高温环境下Flash保持特性下降。后来通过以下改进解决：
- 增加温度补偿：高温时自动提高校验强度
- 定期刷新：每24小时重写一次关键数据
- ECC校验：在软件层实现1bit纠错
另一个教训是关于开发工具链的：某次Keil升级后，原本正常的scatter文件导致RAM代码异常。最后发现是新版本对section对齐要求更严格。现在我的工程里都会保留多个工具链版本的配置文件。
对于需要更高可靠性的场景，建议增加以下防护措施：
- 在电池供电的RTC备份域保存关键指针
- 使用硬件CRC模块加速校验
- 对特别重要的数据采用三副本存储
这个方案经过三年实际项目验证，在智能家居、工业传感器等场景下表现稳定。最关键的是要针对具体应用场景做好异常测试，模拟各种极端情况下的数据恢复能力。