1. 现象复盘RDP 使能后板子为什么像变砖了一样先说结论STM32H725 在使能 RDP Level 1 之后出现“unexpected behavior”十有八九不是芯片坏了而是 RDP 切换过程中的副作用被忽略了。我们前阵子一块 H725 模块在做量产保护时也遇到过一模一样的状况现象相当吓人固件里执行完 RDP 使能代码复位后串口直接没输出ST-Link 也连不上上电电流明显比正常时候低。第一反应是板子废了但冷静下来按流程排查发现是 RDP Level 1 的经典操作逻辑导致的恢复也不难关键是要理解它到底做了什么。1.1 我当时遇到的三个典型“异常”这类问题通常不会只有一个表现我总结下来基本是下面三种你可以对照自己的现象第一种使能后 ST-Link 直接报错比如 “No STM32 target found” 或 “Error: Connection error”。这是因为 RDP Level 1 下调试接口对主 Flash 的访问被限制很多调试器在初始化阶段尝试读 Flash 来识别芯片和获取描述信息读不到就认为目标不存在。第二种能连上调试器但下载固件或者读取 Flash 时失败提示 “Cannot access memory” 或者 “Data read failed”。这种其实很关键——说明芯片没死只是保护生效了外部工具读不了主 Flash。第三种复位后用户程序根本不跑串口没有任何日志连一个变量都不更新。这个现象最容易误判为硬件故障但真正原因往往是 RDP 从 Level 0 切到 Level 1 时芯片执行了整片 Flash 擦除应用代码已经没了。这三种现象可以单独出现也可以同时出现。我们的板子就是第一种加第三种看起来特别像“变砖”。说实话如果当时没有先查参考手册我可能真的会去怀疑是焊接问题或者电源问题。1.2 为什么 H725 上这个问题更容易被放大STM32H725 是一款主频 550MHz 的 Cortex-M7带 L1 Cache、ART 加速器跑起来性能很强但恰恰因为这些特性启用 RDP 后的“异常”会被放大。首先是 Boot 配置更复杂。H725 不像老系列只有一个 BOOT0 引脚决定启动介质它还引入了 BOOT_ADD0/BOOT_ADD1 选项字节可以配置从主 Flash、System Memory、SRAM 甚至外部存储启动。当 Flash 被 RDP 切换清空后如果 BOOT 配置还指向主 Flash 的 0x08000000CPU 启动后取到的全是 0xFF 或者 0x00行为就是“死机”。但这个死机不是 RDP 本身的原因是 Flash 空了。其次H725 的系统存储器和我们常用的 H743 不一样System Memory 的基址大概在 0x0FF00000 附近具体以 RM0468 为准。很多工程是老项目迁移过来的调试脚本里还写死老型号的 bootloader 地址导致 RDP 保护后想用系统 bootloader 恢复工具却找不到正确的启动入口。再加上 M7 的 Cache 会缓存 Flash 内容如果在调试器里做了某些操作后又执行复位Cache 里的旧数据和真实 Flash 内容不一致也会造成“感觉程序在乱跑”的错觉。后面我会专门讲排查步骤这里先有个概念RDP 使能后的异常一半是 RDP 机制本身一半是周围配置被牵动了。2. RDP Level 1 的底层行为它到底对芯片做了什么2.1 三个等级和切换动作先记一张表RDP 是片上 Flash 的读取保护机制在 STM32H725 上分为 Level 0、Level 1、Level 2 三级。很多工程师只记得 “Level 1 不能读 Flash”却忽略了等级切换时的擦除动作。我先把切换行为整理成一张表方便随时对照切换方向是否触发主 Flash 擦除调试器访问可恢复性Level