Bootloader 实战 (3)：Flash 的磨损与保护 —— 驱动层实战

如果说前两篇是在“搭架子”和“通电话”，那么这一篇就是真正的“动手术”。 Flash 驱动层是整个 OTA 中最危险的环节。为什么？因为此时我们是在**“用 Flash 里的程序去擦除 Flash 自己”**。这就像是一个医生在给自己做心脏手术，稍有不慎（比如断电、指针跑飞、看门狗复位），设备直接变砖。

这一篇，我们要讲透IAP（In-Application Programming）的核心技术，特别是如何在 RAM 中运行代码，以及 STM32 和 RL78 在这件事上的巨大差异。

前言 你是否遇到过这样的现象： 在擦除 Flash 扇区的那几百毫秒里，MCU 仿佛死机了一样，串口不再接收数据，指示灯也不闪烁了？ 这是因为大多数单 Bank 的 MCU，不支持同时对 Flash 进行“取指令”和“擦写”操作。 本篇我们将深入驱动底层，解决“总线冲突”问题，并教会你如何给固件穿上一层“防弹衣”（读保护）。

一、 现场还原：为什么 CPU 会“假死”？

首先要建立一个底层概念：总线矩阵 (Bus Matrix)。

• 正常运行时：CPU 通过 I-Bus（指令总线）从 Flash 取指令执行。

• OTA 写入时：CPU 通过 D-Bus（数据总线）向 Flash 控制器发送“擦除/写入”命令。

在大多数 Single Bank（单区） 架构的 MCU（如 STM32F1/F0 或 RL78 全系列）中，Flash 只有一个物理接口。当你命令 Flash 控制器开始“擦除扇区”时，Flash 内部的高压电荷泵启动，整个存储矩阵处于忙碌状态（Busy）。

此时，如果 CPU 试图去 Flash 取下一条指令，Flash 会说：“别烦我，正忙着呢！” 于是，CPU 被迫挂起（Stall），暂停运行，直到擦写结束。这就是“假死”。

后果很严重：

1. 通信中断： 如果此时上位机发来了数据，串口 FIFO 溢出，因为 CPU 没空去搬运数据。

2. 看门狗复位： 如果擦写时间超过了看门狗喂狗时间（比如扇区擦除需要 200ms，看门狗只有 100ms），系统直接重启，变砖。

二、 STM32 的应对：简单粗暴 vs 优雅分身