STM32 的调试口被锁死而且是在烧录 provisioning 工程之后这种问题我遇到过不止一次。最近有个朋友在 NUCLEO-H533RE 开发板上跑 H523 的 provisioning 项目遇到了一个特别典型的情况DADebug Authentication流程显示成功但代码跑起来之后ST-LINK 完全连不上芯片调试口彻底丢失。这个现象很迷惑因为 provisioning 成功后理论上应该处于“可调试”状态结果反而被锁住了。我先把结论放在前面这个问题十有八九不是 DA 流程本身失败而是 provisioning 过程中把 debug 权限配置成了受限模式或者 DA 烧录完成后芯片进入了错误的生命周期状态。H523 和 H533 同属 STM32H5 系列安全架构完全一致所以用 NUCLEO-H533RE 的 provisioning 参考工程去调试 H523 芯片硬件上没问题但配置上的坑一个都不会少。这篇文章我打算从 H5 系列的安全生命周期讲起把 DA 流程到底做了什么、为什么“成功”了却拿不回调试权限、以及怎么一步步排查和恢复完整梳理一遍。如果你也正在用 H5 系列做安全启动或者代码保护这篇内容应该能帮你少走不少弯路。1. 整体设计与思路拆解H5 系列安全体系与 provisioning 的关系1.1 为什么 H523 和 H533 可以共用 provisioning 工程很多人在看到 NUCLEO-H533RE 的 provisioning 示例工程时会有个疑问我用的芯片明明是 H523为什么参考工程是 H533 的这两个型号能通用吗答案是能通用但要注意边界。H523 和 H533 同属 STM32H5 系列都基于 Cortex-M33 内核都集成了 RDPRead Protection、HDPHardware Diversification Protection、Secure Storage 等安全特性最关键的是它们共享同一套 TrustZone 架构和 DA 流程。ST 官方在 NUCLEO-H533RE 板卡的示例工程中实际上已经把 H5 系列共用的安全框架都包含了所以用它来做 H523 的 provisioning 参考在代码层面基本没有障碍。但这里有个容易被忽略的点H523 和 H533 在某些安全特性上并不完全一致比如 Flash 容量和 OBKOption Bytes Key的配置细节可能有差异。这意味着 provisioning 工程生成的配置数据不能无脑直接烧到 H523 里需要针对芯片型号重新生成和校准。很多人在这一步跳过了 check直接用 H533 的配置去烧 H523最后出问题也就不奇怪了。1.2 Debug Authentication 到底在做什么DA 的全称是 Debug Authentication是 H5 系列用于管理调试权限的核心机制。它的作用可以理解成一把“安全钥匙”芯片在出厂时处于开放状态任何人都可以通过调试器读写 Flash但当你启用了 RDP读保护或 TrustZone 后芯片会进入受限状态此时普通的调试器连接就会被拒绝只有拥有正确证书和密钥的设备才能通过 DA 协议重新打开或关闭调试口。从技术原理上讲DA 基于一组由 ST 提供的根密钥和证书链。provisioning 工程做的事情就是把这组密钥、证书以及相关的配置数据烧录到芯片的 OTPOne-Time Programmable区域同时设置生命周期状态。烧录完成后芯片会根据配置决定是否允许调试器访问。这里有个非常关键的概念DA 成功不代表调试口一定打开。DA 成功只代表“认证和授权过程完成了”但授权的结果是什么取决于你在 provisioning 工程里配置的 debug 权限。如果你把权限配置成了 Disabled那么 DA 认证成功之后芯片依然不会开放调试口。这就是标题里说的“DA reports success but cannot regain debug access”的核心原因。1.3 为什么“成功”却失去调试能力结合我实际排查过的情况这个问题通常不是单一原因导致的而是多个因素叠加。第一个因素是生命周期状态的改变。STM32H5 芯片的生命周期包括 STATE_OPEN、STATE_CLOSED、STATE_LOCKED 等几个状态。正常情况下DA 流程应该让芯片在 CLOSED 和 OPEN 之间切换而如果 provisioning 过程中把生命周期设置成了 LOCKED那么这个状态是单向不可逆的芯片会永久锁定调试口就再也回不来了。第二个因素是 RDP 等级配置错误。RDP 分为 Level 0无保护、Level 1禁止外部调试但允许 DA 回归和 Level 2永久保护。如果 provisioning 工程把 RDP 等级设置成了 Level 2那就等于放弃了所有后续调试的可能性。第三个因素也是很多人容易忽略的DA 证书和密钥配置不匹配。NUCLEO-H533RE 的工程默认使用 ST 官方开发板自带的调试证书而如果你手上的是第三方核心板或者自己画的板子芯片里的根密钥和工程里预置的证书可能对不上。这种情况下 DA 流程可能“假成功”——通讯正常、握手正常但最终因为密钥不匹配授权结果无法生效调试口依旧锁死。2. 核心细节解析与实操要点provisioning 工程的关键配置拆解2.1 工程结构到底哪些文件在控制安全状态在 NUCLEO-H533RE 的 provisioning 示例工程里你会看到一堆与安全配置相关的源文件和脚本。初次接触的人很容易迷失在这些文件里不知道哪个才是控制最终安全状态的关键。我这里帮你把核心的部分梳理清楚。首先是DA/目录这里面存放的是 Debug Authentication 相关的证书、密钥和配置文件。具体来说里面有 ST 提供的根证书、开发板的设备证书以及用于生成 DA 配置的脚本。这个目录是整个 provisioning 流程的“身份证”它决定了你的 DA 流程能不能被芯片认可。其次是RDP/相关的配置这些配置决定了读保护等级。你可以通过修改这个配置来设定 RDP Level 0 还是 Level 1。在实际操作中我不建议在初学阶段尝试 RDP Level 2因为一旦烧进去芯片就永久锁死了。再往下是OptionBytes配置文件这个文件控制了很多硬件层面的行为包括看门狗配置、BORBrown-Out Reset等级、以及最重要的 Debug 权限配置。你可能想不到很多“DA 成功但失去调试口”的问题根源就在这个文件的某个位域上。还有一个非常隐蔽的配置是boot lock。在 H5 系列中你可以给 boot 区加锁这样即使通过调试口成功连接也无法读取或改写 boot 区的代码。如果你在 provisioning 工程里意外启用了 boot lock又会多一个“能连上但没权限”的坑。2.2 实操修改 provisioning 工程前的准备工作在动手改任何配置之前我强烈建议你先做两件事第一备份当前能用的烧录配置。用 STM32CubeProgrammer 连接开发板导出当前的 Option Bytes 和 RDP 状态保留一份“健康状态”的快照。万一后面改出了问题这可能是唯一的恢复线索。第二确认芯片型号和板卡版本。H523 和 H533 虽然是同系列但引脚和 Flash 大小有差异这会影响 provisioning 脚本自动生成的地址映射。请仔细阅读工程的 README确认你使用的是匹配的型号定义STM32H523xx而不是STM32H533xx。准备完成后下一步是检查 DA 配置文件中的证书链是否与你的板卡匹配。提示NUCLEO 开发板出厂时ST 会在 OTP 区域写入与该板卡匹配的调试证书。如果你使用的是原装 NUCLEO-H533RE 板卡直接用工程默认配置一般没问题。但如果你的板卡是二手的或者之前被别人烧录过其他密钥证书链可能已经不匹配了。怎么确认呢你可以用 STM32CubeProgrammer 连接板卡在 OBOption Bytes页面查看 Debug Authentication 相关的状态。正常情况下未 provisioning 的板卡会显示 “No DA config” 或类似的提示。如果显示已有配置说明板卡已经不是出厂状态建议优先恢复出厂配置。2.3 实操provisioning 流程的完整步骤这里我把一个标准的 provisioning 流程走一遍并指出每个步骤的易错点。第一步编译 provisioning 工程。在 STM32CubeIDE 中打开工程确认编译宏定义中含有STM32H523xx或STM32H533xx取决于你的芯片。编译时注意看输出如果有任何关于 DA 配置或证书路径的警告不要忽略。第二步用 STM32CubeProgrammer 连接板卡先做一次全擦除Full Flash Erase。这一步是为了清除可能残留的旧配置。命令大致如下STM32_Programmer_CLI -c portSWD modeHOTPLUG -e all第三步烧录 provisioning 所需的初始固件。这个固件通常由工程中预编译好的.elf或.hex文件提供它会在芯片上电后自动执行 DA 配置流程。烧录命令示例STM32_Programmer_CLI -c portSWD modeHOTPLUG -w provisioning.hex -v第四步断电并重新上电。这一步非常关键因为 provisioning 流程一般在上电后的 boot 阶段执行。如果执行成功串口或调试日志中会输出类似 “Provisioning done” 的信息。第五步用 STM32CubeProgrammer 的 DA 连接模式重新连接板卡STM32_Programmer_CLI -c portSWD modeHOTPLUG da./DA/config/DA_config.json如果一切正常命令行会输出认证成功的日志并且芯片恢复可调试状态。但如果你遇到的是“DA 成功但无法调试”问题就出在第四步和第五步之间。下面我会专门展开讲排查方法。2.4 Provisioning 常见配置误区根据我之前帮人解决这类问题的经验有几个配置误区出现的频率特别高第一个是 RDP 等级被误设为 Level 2。在 STM32CubeProgrammer 的界面里RDP 等级的修改非常容易操作但如果你只是点了一下下拉框选成了 Level 2 并 Apply芯片就永久保护了没有任何后悔的余地。这一点请务必警惕。第二个是 DA 配置中选择的 debug 权限错误。在 DA 配置文件中有一项专门控制认证后授予的调试权限通常有Full debug、Restricted debug和No debug三个选项。如果你选了 Restricted 或 No debug即使 DA 认证成功调试器也无法读取 Flash 内容只能执行有限的命令。第三个是 provisioning 工程里默认启用了SECBOOT安全启动。在 H5 系列中SECBOOT 默认是开启的它会强制校验启动代码的签名。如果你后续要烧录自己的应用程序而程序没有经过签名芯片就会一直卡在启动校验阶段表现为“能连接但程序不跑”。这虽然不完全是调试口丢失但很容易被误判为“芯片挂了”。3. 实操过程与核心环节实现从锁死状态到恢复调试口的完整记录3.1 现场现象记录与初步判断我手上这块板子的现象是这样的provisioning 完成后串口日志显示 DA 流程成功然后我尝试用 STM32CubeProgrammer 以 SWD 方式连接结果报错Error: Connection error或ST-LINK error。重新上电后再试依然连不上。用示波器抓 SWDIO 引脚波形发现芯片在收到连接请求后完全没有响应这说明芯片内部的调试端口已经不再响应外部请求。遇到这种情况先别急着判断“芯片废了”。按照我的经验第一步先确认芯片是否还在正常运行。方法很简单看板载 LED 或者串口输出。如果芯片主程序还在跑说明 CPU 没有死只是调试口被关了。如果连程序都不跑那可能是启动流程卡死了问题可能出在 SECBOOT 或 Option Bytes。我这次遇到的情况是主程序还在跑串口持续输出日志但调试口连不上。可以基本锁定问题在 Debug 权限配置而不是芯片硬件损坏。3.2 恢复尝试一使用 DA 重新开放调试口既然 DA 流程报告成功那第一反应自然是再用 DA 连一次看看能不能把调试口重新打开。这里需要用到 DA 配置文件。在 NUCLEO-H533RE 的 provisioning 工程中DA/目录下会生成一个类似DA_config.json的文件里面包含了证书路径、密钥路径和权限设置。用命令行连接时命令是这样的STM32_Programmer_CLI -c portSWD da./DA/config/DA_config.json如果配置正确你会看到类似下面的输出Successful DA authentication Debug access granted这说明 DA 认证通过调试权限被重新授予。但在我这次的现象中即便出现了认证成功SWD 连接依然失败或者只能连接到但立刻断开。这时候你要小心不要让“认证成功”的假象误导判断。DA 认证成功只能说明证书和密钥匹配不代表芯片的调试端口真正打开了。如果配置文件中把调试权限设成了 No debug那么认证的结果就是“认证成功但拒绝调试”。3.3 恢复尝试二检查并修正 Debug 权限配置如果配置文件中确实存在调试权限设置错误那么正确的做法是修改 DA 配置文件把调试权限改回 Full debug然后重新执行 DA。具体来说在DA_config.json或者脚本中会有一项类似debug_authorization的字段值通常是full、restricted或none。如果你之前设置的是restricted或none改成full再试一次STM32_Programmer_CLI -c portSWD da./DA/config/DA_config_new.json从实操经验看如果 provisioning 后立刻发现调试口异常这一步是最有可能解决问题的。但如果你和我一样是在 provisioning 完成后的第 N 次上电才发现的那可能还要处理下面这个更麻烦的情况。3.4 恢复尝试三回到初始状态的“救急方案”如果 DA 配置无法重新打开调试口另一种常用的恢复路径是利用 H5 系列支持的回归流程Regression。但这里有个前提芯片的 RDP 等级必须不是 Level 2。回归流程的思路很简单通过 DA 认证后把芯片的 RDP 等级降回 Level 0同时清除所有安全配置。在 STM32CubeProgrammer 中有一个专门的三级回归按钮或者在脚本命令中执行STM32_Programmer_CLI -c portSWD da./DA/config/DA_config.json obRDP0这个命令的意思是在通过 DA 认证后强制把读保护等级降到 Level 0。如果成功芯片会进入全擦除状态之后你可以重新烧录代码一切归零。注意这个操作会擦除所有 Flash 内容包括 provisioning 配置、密钥、证书等。所以一旦做了回归之前的 DA 配置就没了需要重新 provisioning。如果你的目的只是恢复开发能力那么这是最彻底的方案。但如果芯片的 RDP 等级已经是 Level 2或者生命周期状态已经进入了 LOCKED那么回归流程基本无法执行。这种情况下只能更换芯片。3.5 实操记录本次问题最终如何解决回到我这次的案例。通过逐项排查最终定位到问题出在Option Bytes中的 Debug 权限位。provisioning 工程在烧录时默认把调试权限配置成了 restricted导致 DA 认证通过后只能获得受限调试权限无法读写 Flash。解决方法是修改 provisioning 工程中控制 Option Bytes 的配置文件将调试权限改为 full重新编译并再次执行 provisioning。之后 STM32CubeProgrammer 成功连接烧录恢复正常。多说一句如果你不想重新走一遍 provisioning 流程还有一个临时绕过方案在发现 DA 成功但连不上调试口时立刻按住板子上的 NRST 复位键在复位瞬间尝试连接 SWD。在某些情况下芯片启动早期调试口还处于开放状态可以利用这个时间窗口执行回归命令。这个技巧的成功率取决于芯片启动速度和复位时序不是每次都能成功但值得一试。4. 常见问题与排查技巧实录我踩过的那些坑和对应解法4.1 问题速查表我把 H5 系列上 DA 相关的高频问题整理成了表格方便你对照排查。现象可能原因排查方法解决思路DA 报告成功但调试口无法连接Debug 权限配置为 restricted/none检查 DA 配置文件中 debug_authorization 字段修改为 full 并重新执行 DADA 认证失败提示证书不匹配OTP 中的根密钥与工程证书不匹配检查板卡是否为原厂 NUCLEO确认是否二次 provisioning更换匹配的 DA 配置或恢复出厂板卡配置芯片完全无响应NRST 后也无法连接RDP Level 2 或生命周期进入 LOCKED尝试回归命令查看芯片电源和时钟如果无法回归只能更换芯片能连接调试器但程序不跑SECBOOT 启用导致签名校验失败检查启动日志查看 SECBOOT 配置关闭 SECBOOT 或对程序签名DA 命令执行后连接不稳定SWD 时序问题或线缆过长降低 SWD 速率使用更短的杜邦线在 STM32CubeProgrammer 中设置频率为 4MHz 以下4.2 独家避坑技巧这些细节没人告诉你我在折腾 H5 系列安全功能时积累了不少经验有几个细节特别值得拿出来分享。第一个是关于 STM32CubeProgrammer 的版本。DA 功能在不同版本的工具中实现差异很大。老版本可能根本不支持 DA或者支持和 H5 系列的连接方式不同。我建议统一使用最新的 STM32CubeProgrammer至少在 2.14 以上。版本不对DA 流程的成功率和稳定性都会打折扣。第二个是 SWD 连接速率。很多人忽略了这个看似无关紧要的参数。在 provisioning 之后芯片内部可能还残留了一些安全校验逻辑如果 SWD 速率过高连接过程中容易出错表现为“时好时坏”的诡异现象。遇到这种情况先把速率降到 4MHz 以下再试。第三个是要学会利用--modeHOTPLUG连接参数。HOTPLUG 模式会跳过芯片的启动流程直接访问调试端口在芯片卡死在启动阶段时非常有用。很多“连不上”的问题用 HOTPLUG 模式就能绕过。第四个是关于二次 provisioning 的注意事项。如果你已经对芯片做过一次 provisioning重新再烧录一次 provisioning 工程时必须先执行全擦除和回归否则 DA 配置会叠加导致状态混乱。这就像在一个已经装了系统的硬盘上再装一次系统不格式化就会冲突。4.3 如何彻底避免我的建议流程经过多次折腾我现在做 H5 系列开发时已经形成了一套固定的操作流程可以最大程度避免把芯片锁死的风险。首先在开始任何涉及 provisioning 或 RDP 的操作之前我会先截一个系统当前的 Option Bytes 快照。用 STM32CubeProgrammer 的 OB 页面导出一个文本文件保存所有选项字节的当前值。这个文件在你需要恢复现场时是救命稻草。其次第一次烧录 provisioning 工程时我会故意把 RDP 等级保持在 Level 0先验证 DA 配置本身是否正常确认 DA 能成功连接并切换调试权限之后再去提升保护等级。不要一上来就全部拉满给排查留出余地。再次我会把 provisioning 工程和应用程序工程分开管理。provisioning 只负责安全配置和 DA 设置应用程序则是纯功能逻辑。这样可以避免在每次烧录应用代码时都去触碰安全配置减少误操作的风险。最后如果你真的在一个非常重要的项目上用了 provisioning 并且已经锁死了芯片建议直接换一片新芯片把锁死的芯片留着做安全逃生实验。比起不断尝试各种恢复命令浪费的时间一片开发板芯片的成本其实低得多。5. 延伸思考理解 H5 系列安全模型的底层逻辑5.1 生命周期状态机为什么“成功”不一定等于“开放”如果你一路看到这里应该已经理解了 DA 成功和调试口开放不是一回事。为了把这层逻辑彻底讲透我再展开说一下 H5 系列的生命周期状态机。H5 系列芯片内部维护了一个安全生命周期状态机常见状态包括STATE_OPEN出厂状态调试口完全开放RDP 为 Level 0所有人都能读写 Flash。STATE_CLOSED受保护状态RDP 至少为 Level 1调试口默认关闭只有通过 DA 认证才能临时打开调试权限。STATE_LOCKED永久锁定状态所有调试功能禁止DA 也不可恢复只能更换芯片。provisioning 的核心目的就是让芯片从STATE_OPEN切换到STATE_CLOSED同时把 DA 所需的密钥和证书写入 OTP。而 DA 认证的作用则是在STATE_CLOSED状态下通过安全握手临时授予调试权限。注意这里的关键词是“临时”。每次复位之后调试口都会重新回到关闭状态必须再次执行 DA 才能打开。这个设计和传统的 MCU 完全不同。传统 MCU 上你只需要用调试器连上就能读 Flash而 H5 系列把调试权限拆成了“物理连接”和“安全授权”两层。很多刚接触 H5 的人包括我最初都会下意识用传统 MCU 的思路去操作结果就是被安全机制狠狠教育了一番。5.2 DA 的根密钥体系为什么板卡不能乱用H5 系列的 DA 机制建立在公开密钥基础设施PKI之上。ST 在芯片出厂时会在 OTP 区域写入一对设备独有的密钥对公钥用于验证外部 DA 请求的签名私钥则永远不会泄露。为了便于开发ST 的 NUCLEO 开发板默认使用 ST 公开的 DA 配置也就是开发板里的公钥和 ST 提供的证书是匹配的。所以你直接用工程默认配置就能完成 DA 认证。但如果你用的是自己画的板子或者从非正规渠道购买的散料芯片芯片里的根密钥可能和 ST 公共证书不匹配就必须通过 STM32TrustedPackageCreator 或者其他工具生成对应的密钥和证书并把公钥烧录到芯片的 OTP 中。很多人的“DA 报告成功但无法调试”问题其实就出在这个环节可能板卡上的证书已经变了但工程里的配置还是默认的 ST 证书。DA 流程的握手可能已经完成但证书验证失败最终授权没有被芯片接受。如何确认呢在 provisioning 完成前先用 STM32CubeProgrammer 读一下 OTP 里与 DA 相关的区域看看里面是否已经有内容。如果已经有内容且不是全 F说明芯片可能已经被动过手脚。5.3 TrustZone 对调试权限的额外影响值得一提的还有 TrustZone。H523 和 H533 都支持 TrustZone而 TrustZone 的启用状态会影响调试权限的分配。启用 TrustZone 后芯片的 Flash 和 RAM 会被划分为安全和非安全两个区域。调试器可以配置为只允许调试安全区、只允许调试非安全区或者两者都允许。在 provisioning 工程中如果只给非安全区授予了调试权限而你的应用程序跑在安全区就会遇到“能连上但看不到程序”的诡异问题。这种情况的排查方法相对简单在 DA 配置或调试器的选项中把安全区和非安全区的调试权限都打开。在 STM32CubeProgrammer 里连接设置中一般有Secure debug和Non-secure debug的选项确保两者都勾选。5.4 H5 系列安全开发的技术选型建议我把前面所有经验汇成几句直接的建议。如果你的项目中使用的芯片需要防止代码被读取又希望保留后续现场调试的能力那么 H5 系列的 DA 机制是目前 MCU 里做得比较完善的方案。但前提是你必须理解 DA 的工作机制并且不要把 RDP Level 2 当成“安全感的来源”。Level 2 意味着彻底的锁定调试口和回归路径都没有了。如果你的项目只是常规的固件开发不涉及代码保护那我建议暂时不要碰 provisioning 和 RDP保持出厂状态即可。安全功能的调试复杂度会显著拖慢开发进度确实没必要为了“显得专业”去折腾。如果你的团队有多个开发人员共用一块板子建议为每个开发人员准备独立的 NUCLEO 板卡。因为 DA 配置和板卡绑定换人调试时证书不匹配又会出现“DA 成功但连不上”的问题。6. 一些额外的操纵技巧和注意事项6.1 利用 STM32TrustedPackageCreator 生成自定义密钥如果你需要在自己的板卡上启用 H5 系列的安全功能就不能依赖 ST 的默认证书需要自己生成一套密钥和证书。这个过程使用的是 STM32TrustedPackageCreator 工具它在安装 STM32CubeProgrammer 时会一并安装。具体操作流程是打开 STM32TrustedPackageCreator选择对应的芯片型号然后在 DA 配置页面生成新的密钥对和证书。生成后会得到一组.pem格式的证书文件和.key格式的私钥文件。这些文件需要在 provisioning 工程中逐一引用。这里有个非常关键的细节生成的公钥必须提前烧录到芯片的 OTP 区域否则芯片在验证 DA 请求时无法找到匹配的证书。这个烧录动作可以放在 provisioning 流程的第一步或者通过 Option Bytes 设置完成。我在测试中发现很多人忘记这一步导致 DA 认证一直失败却把锅甩给 ST 的工具其实问题出在自己的操作顺序上。6.2 如何安全地用一个 DA 配置同时管理多块板卡实际项目中很多时候你需要同时管理多块板卡让它们能够通过同一个 DA 配置进行调试。这个需求完全可以实现方法是在生成密钥对时把同一个公钥烧录到所有板卡的 OTP 中。这样做的风险是一旦某块板卡丢失持有私钥的人就可以通过 DA 获取调试权限。所以在生产环境中公钥烧录和私钥保管需要严格分离。私钥应该存放在安全的管理员环境中普通开发人员只使用 DA 请求工具不接触私钥文件。6.3 调试口丢失后的几条实用操作建议如果你现在正面对一块“DA 成功但无法调试”的板卡我最后给你几个直接可操作的建议。无论如何先把 DA 配置文件检查一遍确认 debug 权限是 full。这一步可以用五分钟完成却能解决一半以上的问题。然后用 HOTPLUG 模式加低速率连接试一次。注意是 HOTPLUG 模式不是普通的 SWD 连接。很多连不上的情况在 HOTPLUG 模式下都能连接成功。再试试在复位瞬间发送 DA 请求。具体方法是在 STM32CubeProgrammer 的 DA 配置界面点击执行 DA 的同时手动按下板卡的 NRST 按键。这种“雷电操作”虽然成功率不稳定但在某些时序条件下可以抓住芯片启动早期的调试窗口。如果以上都不行那么老老实实做回归操作。但前提是芯片的 RDP 等级不是 Level 2。如果已经是 Level 2那就直接换芯片吧不要在这块芯片上继续浪费时间了。以我个人实际折腾 H5 系列的经验最不值当的做法就是在一个已经锁死的芯片上反复尝试各种恢复命令。芯片单价不高时间成本高。锁死了就换一片把原始问题记录清楚下次烧录前检查好配置这才是最提高生产力的路径。