企业官网建设流程全解析

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 的 0x08000000，CPU 启动后取到的全是 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”，却忽略了等级切换时的擦除动作。我先把切换行为整理成一张表，方便随时对照：