在嵌入式开发中，许多工程师都曾经历过这样的绝望时刻：产品即将量产，却发现存储在Flash中的数据神秘丢失或损坏；系统运行中偶尔死机，追踪数周才发现是Flash操作引发的中断异常；或者更糟产品出厂数月后因Flash磨损导致批量故障。
今天，就让我们一起揭开MCU驱动Flash读写背后的技术陷阱，这些经验教训都来自于真实项目的血泪史。
在深入探讨陷阱之前，我们先来了解Flash存储器的基本特性。Flash分为NOR Flash和NAND Flash两种，MCU中通常使用NOR Flash，因为它支持随机读取，适合存储程序代码。Flash的典型操作包括：
- 读取：可以按字节或任意大小读取数据，速度较快。
- 写入：只能将1改为0，且通常需要先擦除目标区域。
- 擦除：将整个扇区或块置为全1（0xFF），耗时较长。
HAL_FLASH_Unlock(); // 解锁Flash FLASH_EraseInitTypeDef EraseInitStruct; EraseInitStruct.TypeErase = FLASH_TYPEERASE_SECTORS; EraseInitStruct.Sector = FLASH_SECTOR_5; // 指定扇区 EraseInitStruct.NbSectors = 1; // 擦除1个扇区 uint32_t SectorError; HAL_FLASHEx_Erase(&EraseInitStruct, &SectorError); // 执行擦除 HAL_FLASH_Lock(); // 锁定Flash
时序管理不当
Flash的擦除和写入操作耗时较长（擦除可能需要几毫秒，写入每字节约50μs）。如果开发者未等待操作完成就进行后续操作，可能导致数据不完整或程序错误。
所以操作完成后可以使用状态寄存器或标志位检查操作是否完成。
读写冲突
在某些MCU中，Flash在写入或擦除期间无法同时读取。如果程序尝试在Flash操作期间从Flash读取代码或数据，可能会引发总线错误或硬故障。
为了避免这种情况，可以在Flash操作期间禁用中断，确保处理器不访问Flash。
误解代码执行方式
许多开发者误以为MCU程序会从Flash复制到RAM执行。实际上，大多数MCU直接从Flash执行代码，只有在特定高性能场景下才将代码复制到RAM。这种误解可能导致错误的内存分配或性能优化策略。
错误分配内存
在定义变量时，如果未明确指定存储位置，编译器可能默认将变量分配到RAM中。但对于需要掉电保存的数据，应存储在Flash中。反之，将大段代码或数据错误分配到Flash可能导致性能下降。
所以要合理规划内存分配，避免RAM溢出或Flash空间浪费。
忽略擦写次数限制
Flash存储器的擦写次数有限，通常为10,000至100,000次/扇区。频繁写入同一扇区可能导致存储器失效。例如，在存储频繁更新的参数时，可能很快耗尽擦写寿命。解决方案如下：
- 减少不必要的Flash写入，使用RAM缓存数据，仅在必要时写入Flash。
- 实现磨损均衡，通过轮换使用多个扇区分散擦写次数。在同一扇区内轮流写入多份数据，待存满后再统一擦除，可实现寿命提升。
- 选择耐久性更高的存储器（如EEPROM）用于高频写入场景。
缺乏数据验证
写入Flash后，未验证数据是否正确写入，可能在使用时发现数据错误。例如，STM32社区曾报告因未验证Flash内容导致读取错误数据的问题。
最简单的办法是写入后读取数据，比较是否一致。例如使用校验和或CRC验证数据完整性。
Flash 是 MCU 上最珍贵的“非易失存储”资源，其特性决定了操作细节万万不可掉以轻心。务必严格参照数据手册、采用完善的擦写流程、做好磨损均衡与中断管理，才能确保系统可靠运行，延长产品寿命。
STM32
MCU
通讯及无线技术
物联网技术
电子DIY
板卡试用
基础知识
软件与操作系统
我爱生活
小e食堂
