应采用带状态标记与CRC校验的多槽位模拟EEPROM结构：在单扇区中划分多个固定大小槽位，每槽含状态标志、CRC32及配置数据；写入时查找空闲槽写新副本并作废旧槽，读取时遍历选取最新有效且校验通过者。
为什么不能直接用Flash地址写配置
单片机内置Flash擦写有硬性限制：必须按扇区擦除（比如STM32F1是1KB/扇区），而写入只能按字（32位）或半字（16位）进行，且写前必须确保目标地址已擦除为0xFF。直接把struct config memcpy到Flash地址会触发硬件异常或静默失败——因为没擦就写，或者跨了扇区边界。
更关键的是：Flash寿命通常只有1万~10万次擦写，而配置可能每分钟保存一次。必须避免频繁擦除同一扇区。
- 每次保存前先判断值是否真有变化，跳过无意义写入
- 用“页轮转”或“地址偏移+状态标记”实现多份副本，分散擦写压力
- 禁止在中断上下文调用Flash写函数，必须关中断或确保调度安全
怎么设计一个带校验的模拟EEPROM结构
典型做法是在一个Flash扇区（如1KB）里划分多个固定长度的“槽位”，每个槽位存：1字节状态标志 + 4字节CRC32 + N字节配置数据。状态标志用0xAA表示有效、0x55表示已废弃、0xFF表示未使用。
写入时不是覆盖旧数据，而是找下一个空闲槽位写入新副本，并把旧槽位状态刷成0x55。读取时遍历所有槽位，选状态为0xAA且CRC校验通过的最新一份（靠地址递增顺序隐含时间戳）。
立即学习“C++免费学习笔记（深入）”；
// 示例槽位布局（每个槽位32字节）
struct eeprom_slot {
uint8_t flag; // 0xAA = valid, 0x55 = invalid
uint32_t crc; // CRC32 of data[0..27]
uint8_t data[27]; // your config struct padded to 27 bytes
};
- 槽位大小必须是Flash编程粒度的整数倍（如STM32F1要求32位对齐，即4字节）
- CRC必须在写入前计算，且不能包含
flag和crc自身字段 - 首次初始化时，整个扇区需预先擦除，否则残留数据可能被误判为有效
STM32 HAL库下怎么安全擦除并写入Flash
HAL_FLASH_Unlock()之后必须立刻调用HAL_FLASHEx_Erase()，不能穿插其他操作；擦除完成前调用HAL_FLASH_Program()会失败。而且擦除是阻塞操作，F1系列1KB扇区约耗时20~40ms，必须预留足够时间窗口。
写入时务必检查返回值：HAL_OK不等于成功——要再用FLASH_WaitForLastOperation()确认，否则可能写到一半被中断打断导致数据错乱。
- 擦除前用
HAL_FLASHEx_EraseIsBusy()确认无后台操作 - 写入每个字（
HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, addr, data)）后都应检查返回值，非HAL_OK立即中止 - 写完必须执行
__DSB()和__ISB()指令，防止指令预取缓存读到旧值
掉电瞬间怎么避免配置写到一半变砖
没有超级电容或后备电源时，唯一可靠办法是：只在确定系统即将长期运行（比如开机自检完成、网络连通、用户点击“保存”）后再触发写入；绝不响应按键长按、串口指令等不可控事件的实时保存请求。
若必须支持断电保护，需配合电压监测（如STM32的VREFINT通道+比较器）：当检测到VDD跌至某阈值（如2.8V），立刻置位“紧急保存标志”，然后在主循环中尽快完成当前写入并进入低功耗停机——但注意，此时Flash写操作本身耗电可能加速掉电，反而得不偿失。
- 所有Flash操作前后加
__disable_irq()/__enable_irq()，防中断打断擦写序列 - 写入前把配置数据memcpy到RAM静态缓冲区，避免写过程中原结构被修改
- 实际产品中建议保留至少2个完整扇区：一个主区，一个备份区，主区损坏时可从备份恢复
真正的难点不在代码怎么写，而在如何定义“配置变更”的语义边界——比如Wi-Fi密码改了必须存，但信号强度这种动态值绝不能存。这个逻辑漏掉，再健壮的Flash模拟层也救不回反复擦坏的扇区。
