关键在采用A/B双分区机制：升级时仅擦写备用分区，校验通过后切换启动标记，确保活动分区始终保留可启动的旧固件；Bootloader须严格验证CRC与状态标记，并禁用自身OTA。
OTA升级时如何避免固件损坏导致设备变砖
关键在写入新固件前，必须保留一份可启动的旧固件副本。嵌入式系统没有操作系统兜底，flash写一半断电或校验失败，若唯一固件被覆盖就无法恢复。双备份不是“两份都存”，而是用「活动分区（active）+ 备用分区（inactive）」加「启动标记」协同控制——每次升级只擦写备用分区，成功后再切换标记。
常见错误是直接在运行分区上覆盖写入：write_flash(0x08000000, new_fw)，一旦中断，0x08000000处代码已损毁且无回退路径。
- 硬件需至少划分两个独立 flash 区域（如
0x08000000–0x0803FFFF和0x08040000–0x0807FFFF），大小不小于最大固件镜像 - 每个分区头部预留 16 字节元数据区，存 CRC32、版本号、状态标记（
VALID/INVALID） - Bootloader 启动时只加载状态为
VALID且 CRC 校验通过的分区，否则跳转到另一分区
如何用 C++ 在裸机环境安全擦写 flash 并校验
裸机 C++ 没有 STL 容器和异常，所有 flash 操作必须手动管理地址、页擦除顺序、写保护位。STM32 常见错误是调用 HAL_FLASHEx_Erase() 前未解锁 FLASH_CR 寄存器，或擦除后未检查 HAL_FLASH_GetError() 返回值就继续写入。
示例关键流程（以 STM32H7 为例）：
立即学习“C++免费学习笔记（深入）”；
// 1. 解锁 flash
HAL_FLASH_Unlock();
__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS);
// 2. 擦除目标页（注意：必须按页对齐，且一次最多擦一页）
FLASH_EraseInitTypeDef erase = {0};
erase.TypeErase = FLASH_TYPEERASE_PAGES;
erase.Page = FLASH_PAGE_32; // 对应 0x08040000 起始页
erase.NbPages = 64; // 覆盖整个备用分区所需页数
uint32_t page_error = 0;
HAL_FLASHEx_Erase(&erase, &page_error);
// 3. 写入前逐字检查目标地址是否已擦净（0xFF）
for (uint32_t addr = 0x08040000; addr < 0x08080000; addr += 4) {
if (*(volatile uint32_t*)addr != 0xFFFFFFFFU) {
// 擦除失败，中止升级
goto fail;
}
}
// 4. 写入新固件（32位字对齐，禁用缓存）
HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, addr, word);
- 写入必须用
HAL_FLASH_Program()而非 memcpy，否则绕过 flash 控制器，触发硬 fault - 每写完一页（通常 2–128KB），必须调用
__DSB()指令确保写入完成，再读回校验 - CRC 计算必须包含完整固件 + 元数据，且在校验通过后才更新该分区的元数据状态为
VALID
Bootloader 怎么识别并切换 active/inactive 分区
切换不是改指针，而是改一个存储在独立扇区（如最后一页）的「启动配置结构体」。这个结构体不能和任一分区耦合，否则升级时可能被误擦。
典型结构：
struct boot_cfg {
uint32_t active_offset; // 当前运行分区起始地址偏移（如 0 或 0x40000）
uint32_t crc32; // 本结构体自身 CRC
};
Bootloader 启动流程：
- 读取
boot_cfg，验证其crc32；若失败，尝试从默认地址（0x08000000）启动 - 根据
active_offset计算实际启动地址（0x08000000 + active_offset） - 跳转前检查该地址处固件头的
VALID标记和 CRC —— 任一失败则尝试另一分区（active_offset取反） - OTA 升级成功后，仅更新
boot_cfg.active_offset并重写 CRC，不碰任何固件区
容易忽略的是：某些芯片（如 GD32）复位后会从 0x08000000 固定地址取向量表，所以必须用 SCB->VTOR = active_base_addr 动态重定向中断向量，否则中断仍指向旧分区地址。
为什么双备份不能解决所有问题，还要加看门狗和升级超时
双备份防的是「固件内容损坏」，但防不了「升级过程卡死」。比如 OTA 下载中断后，设备反复重启进入 Bootloader，又因网络不可用一直卡在等待下载，最终耗尽电池或被用户强制断电。
- 必须在 Bootloader 中启用独立看门狗（IWDG），每次进入下载等待前喂狗，超时未收到完整固件则自动回退到原分区
- 升级标志位（如
ota_in_progress）要存在独立 backup SRAM 或 RTC 寄存器里，掉电不丢失；否则重启后无法判断上次是否中断在半途 - 新固件首次启动时，需在应用层主动上报「启动成功」给 Bootloader（例如写特定寄存器值），Bootloader 等待 5 秒无响应即视为启动失败，回退
最易被忽略的一点：双备份机制本身依赖 Bootloader 的可靠性。如果 Bootloader 有 bug（比如 CRC 计算漏字节、状态标记写错地址），整个恢复链就失效。因此 Bootloader 必须比应用固件更严格测试，且禁止 OTA 升级 Bootloader 自身——它得靠 JTAG 烧录更新。
