STM32H563执行HAL_FLASH_OB_Launch是否触发系统复位？

核心结论：HAL_FLASH_OB_Launch会触发系统复位 #

STM32H5系列中，HAL_FLASH_OB_Launch()的作用是触发选项字节（OB）加载生效。根据硬件设计，修改WRP（写保护）类选项字节后，必须通过系统复位才能让新配置生效——该函数内部会置位FLASH_CR寄存器的OBL_LAUNCH位，直接触发MCU复位。

现象解析 #

• 正常运行时执行后I2C返回全0xFF：MCU复位后，I2C外设尚未完成初始化，通信返回无效数据；复位后程序重启，业务上下文已丢失，导致通信异常。
• Keil调试中能继续执行后续代码：调试器会在MCU复位后自动重新连接并恢复调试上下文，看似程序连续执行，实则MCU已完成一次复位，这是调试器的特殊处理逻辑。

无复位实现写保护的可行思路 #

需要明确：STM32H5的硬件WRP配置必须通过复位才能生效，无法在不复位的情况下直接启用新的写保护规则。但可以通过以下方式优化流程，降低复位影响：

1. 复位前后状态衔接

   • 执行HAL_FLASH_OB_Launch()前，将必要的业务状态（如I2C通信标记、当前任务进度）保存到未被写保护的Flash区域；复位后，程序启动时优先读取该状态，快速恢复业务流程，比如重新初始化I2C并恢复通信链路。

2. 清理冗余代码

   • 你代码中HAL_FLASH_OB_Launch()后的HAL_FLASH_OB_Lock()和HAL_FLASH_Lock()完全无效：复位后锁状态会被重置，且复位前函数已触发复位，后续代码根本不会执行（调试场景除外）。建议删除这两行：

     // 以下两行在OB_Launch后不会执行，可删除
     // HAL_FLASH_OB_Lock();
     // HAL_FLASH_Lock();
     

3. 验证WRP配置准确性

   • 确认WRPSector计算正确：BIT(0)对应Bank2的具体扇区需对照STM32H563 Flash映射表，避免误配置导致保护区域不符合预期。

替代方案（严格无复位场景） #

如果应用场景绝对不能复位，只能采用软件层面的写保护：在代码中对特定Flash区域的写入操作添加权限校验逻辑。但这种方式安全性远低于硬件WRP，可通过调试或代码篡改绕过，仅适用于非高安全要求场景。

内容的提问来源于stack exchange，提问作者Wen Hua