EEPW论坛

在嵌入式开发中，许多工程师都曾经历过这样的绝望时刻：产品即将量产，却发现存储在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 上最珍贵的“非易失存储”资源，其特性决定了操作细节万万不可掉以轻心。务必严格参照数据手册、采用完善的擦写流程、做好磨损均衡与中断管理，才能确保系统可靠运行，延长产品寿命。