Flash erase过程中电压异常处理指南

Flash擦除过程中电压异常的实战防护：从原理到代码的全链路设计

你有没有遇到过这样的场景？设备在野外运行，固件升级进行到一半，突然断电重启——结果系统再也无法启动，用户只能返厂维修。这种“变砖”问题，十有八九出在Flash erase阶段的电压异常处理不当。

随着物联网、汽车电子和工业控制对可靠性的要求越来越高，我们不能再把Flash操作当作简单的读写函数调用。尤其是在擦除阶段，一旦电源波动，轻则数据错乱，重则芯片永久损坏。本文将带你深入剖析这一过程中的风险点，并提供一套可落地的软硬件协同防护方案。

为什么Flash擦除特别怕电压不稳？

很多人知道Flash要先擦后写，但很少思考背后的物理代价。

现代NOR/NAND Flash基于浮栅晶体管（Floating Gate MOSFET）实现非易失存储。当我们要将某个扇区“清零”（实际上是恢复为逻辑1），就需要把浮栅里的电子“抽走”。这个动作依赖的是Fowler-Nordheim隧穿效应—— 而它需要一个关键条件：足够高的电场强度。

为了产生这个电场，芯片内部会启动电荷泵电路（Charge Pump），把1.8V或3.3V的供电升压到8–12V以上。这个过程持续数毫秒，在此期间：

工作电流骤增（可达十几mA）
对电源纹波极为敏感
一旦电压跌落超过阈值，高压无法维持 → 擦除失败

更危险的是，如果此时强行复位或断电，存储单元可能处于半擦除状态：既不是全0也不是全1，下次写入时会出现不可预测的行为。这就像拆房子只拆了一半，再往上盖新楼，迟早塌方。

🔍 实际案例：某车载T-Box模块在低温环境下频繁升级失败，最终定位是LDO负载调整率不足导致擦除期间电压跌至2.4V，而其Flash要求最低2.7V才能完成块擦除。

硬件防线第一关：BOD不只是“欠压复位”

很多工程师认为Brown-out Detection（BOD）就是检测到电压低就自动复位。其实远远不止。

真正可靠的系统应该做到：在电压还没掉到危险水平之前，就已经做出反应。这就需要用到现代MCU中更精细的电源监控机制。

BOD vs SVS：谁更适合擦除保护？

特性	BOD（Brown-out Reset）	SVS（Supply Voltage Supervisor）
触发动作	强制复位	可配置中断或标志位
响应速度	<1μs	~1–5μs
可控性	低（复位即失控）	高（软件可干预）
适用场景	最终兜底	主动防御

👉结论：如果你希望在电压下降初期还能执行一些安全收尾操作（比如暂停Flash任务、保存上下文），那就必须使用SVS而非直接依赖BOD复位。

以STM32系列为例，你可以设置多个电压监测等级：

// 设置SVS在2.7V触发警告中断 HAL_PWREx_EnableVoltageWarningLevel(PWR_VDD_UNDER_2V7);

这样，当系统电压滑向擦除临界值时，先来个“黄牌警告”，留出时间做准备。

Flash控制器的“自我保护协议”：别指望它永远听话

即使你做好了电源设计，也不能假设Flash控制器会在异常下“优雅退出”。

事实上，大多数嵌入式Flash IP都内置了状态机锁死机制：一旦开始erase，就必须完成或硬复位，否则总线会被锁定，CPU卡死。

但这并不意味着它没有错误反馈能力。关键在于如何正确解读它的“语言”——也就是那些隐藏在寄存器里的状态标志。

必须关注的核心状态位

标志位	含义	如何处理
`ERASE_ERROR`	擦除未完成	禁止后续写入，记录故障日志
`PROG_ERROR`	编程失败	可能因前次擦除失败引起
`BUSY`	操作仍在进行	轮询时必须等待清零
`WRPERR`	写保护冲突	地址越界或受保护区域访问

这些标志不仅能在操作后读取，有些还支持通过中断方式通知CPU。例如在GD32中，可以启用EOP（End of Operation）中断来避免轮询浪费资源。

安全擦除函数怎么写？别让裸机API害了你

下面这段代码看似标准，实则埋雷：

HAL_FLASHEx_Erase(&erase_cfg); // 直接调用，无检查

正确的做法是构建一个带前置检查 + 异常捕获 + 结果验证的安全封装层。

✅ 推荐的安全擦除模板（适用于多数MCU）

typedef enum { FLASH_OK = 0, FLASH_LOW_VOLTAGE_ERROR, FLASH_BUSY, FLASH_ERASE_ERROR, FLASH_VERIFY_ERROR } FLASH_StatusTypeDef; FLASH_StatusTypeDef Safe_Erase_Sector(uint32_t sector_addr) { // Step 1: 前置条件检查 float vdd = Get_System_Voltage(); // ADC采样或PMU获取 if (vdd < 2.7f) { // 典型最小擦除电压 return FLASH_LOW_VOLTAGE_ERROR; } // Step 2: 清除旧状态标志 __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR); // Step 3: 执行擦除 FLASH_EraseInitTypeDef erase_cfg = { .TypeErase = FLASH_TYPEERASE_SECTORS, .Sector = ADDR_TO_SECTOR(sector_addr), .NbSectors = 1, .VoltageRange = FLASH_VOLTAGE_RANGE_3 // 匹配电压区间 }; uint32_t page_error = 0; HAL_StatusTypeDef status = HAL_FLASHEx_Erase(&erase_cfg, &page_error); if (status != HAL_OK) { Log_Flash_Error(ERROR_CODE_ERASE_FAIL, sector_addr); return FLASH_ERASE_ERROR; } // Step 4: 验证是否真的全为0xFF if (!Verify_Erased_Sector(sector_addr)) { Mark_Block_For_Recovery(sector_addr); // 加入待修复队列 return FLASH_VERIFY_ERROR; } return FLASH_OK; }

📌 关键点解析：
-VoltageRange必须与当前VDD匹配，否则驱动能力不足
- 即使HAL返回OK，也要做数据验证（读取并确认所有字节为0xFF）
- 失败后不应立即重试，应标记状态供上电自检处理

上电怎么办？异常恢复策略决定产品寿命

最怕的不是出错，而是出错之后不知道怎么收场。

设想一下：设备正在擦除配置区，突然断电。下次上电时，你怎么判断上次操作到底完成了没？

设计一个“事务状态标记”机制

我们可以引入简单的状态标记来追踪关键操作：

#define ERASE_STATE_IDLE 0xA0A0 #define ERASE_STATE_PENDING 0xB1B1 #define ERASE_STATE_COMPLETED 0xC2C2 // 在RAM中缓存当前状态（也可放备份SRAM） static uint16_t g_erase_state = ERASE_STATE_IDLE; // 开始擦除前写入“待处理” void Start_Erase_Operation(uint32_t addr) { g_erase_state = ERASE_STATE_PENDING; Backup_Write(FLASH_CTRL_BLOCK, &g_erase_state); // 写入后备区域 Cache_Clean(); // 确保刷入 } // 成功完成后更新为完成态 void Complete_Erase_Operation(void) { g_erase_state = ERASE_STATE_COMPLETED; Backup_Write(FLASH_CTRL_BLOCK, &g_erase_state); }

然后在系统初始化早期加入恢复逻辑：

void System_Init_Recovery_Check(void) { uint16_t state = Backup_Read(FLASH_CTRL_BLOCK); switch(state) { case ERASE_STATE_PENDING: // 上次擦除未完成 → 尝试补擦 if (Safe_Erase_Sector(g_pending_addr) == FLASH_OK) { Complete_Erase_Operation(); } else { Handle_Erase_Failure_Permanently(); // 标记坏块 } break; case ERASE_STATE_COMPLETED: // 正常流程 break; default: // 初始状态或非法值，按安全模式处理 break; } }

💡 提示：这类标记不要放在主Flash控制块，建议使用独立的备份SRAM或专用OTP区域，防止被误擦。