做 STM32H563/573 调试端口接入，或者叫“Access via Debug Port”，确实是一块容易让人踩坑的工作。别看 SWD 就是四根线的事情，到了带 TrustZone 的 Cortex-M33 平台上，Debug Port 的访问牵扯到芯片安全状态、调试认证、选项字节、低功耗模式等多个维度，稍不注意就是连不上、读不了、擦不掉。这篇文章我结合自己调试 H563 系列的实际经验，把 Debug Port 访问这件事从原理到操作完整梳理一遍。
先说清楚这是做什么的。STM32H563/573 是ST基于 Cortex-M33 内核的高性能 MCU，主频 250MHz，带 TrustZone 安全扩展，内部集成 ART 加速、大量模拟外设和丰富通信接口。这里的“Debug Port”主要指 SWD（Serial Wire Debug）和 JTAG 两种调试物理接口，通过它可以连接调试器（ST-Link、J-Link、DAPLink 等），实现程序下载、Flash 读取、运行时变量观察、断点调试以及故障现场分析。这篇文章适合正在做 H563/573 驱动的嵌入式工程师、做产品量产准备的硬件工程师，以及被“连不上调试器”折磨的初学者。整套思路和操作步骤在 H5 系列其他型号上也通用。
1. 调试接口背后的安全架构：为什么 H563/573 不只是一根线的事
1.1 Cortex-M33 内核调试基础设施
先补一个基础概念。STM32H563/573 的调试系统是 ARM CoreSight 架构的一部分，在芯片内部是一个完整的调试子系统，而不只是引脚上那几根线。整个调试通道从外部调试器到内核大致经过这样一条链路：调试引脚（SWDIO/SWCLK）→ 调试端口接口单元（DP）→ 调试访问端口（AP）→ 总线矩阵 → Cortex-M33 内核调试寄存器。
SWD 协议只有两根线：SWDIO 负责双向数据传输，SWCLK 提供时钟。相比 JTAG 的四线（TMS/TCK/TDI/TDO），SWD 在引脚占用和布线便利性上优势明显，这也是现在 ST 芯片调试几乎默认走 SWD 的原因。H563/573 的调试引脚默认复用功能是 AF0，也就是上电默认就是调试功能，不需要额外配置。但注意，如果你在代码里把这些引脚配置成 GPIO 或者其他复用功能，调试口就没了。
这里有个关键点：Cortex-M33 的调试接口比老内核多了一个概念叫 Security Attribution，也就是每一个调试访问请求都会被安全属性检查。一个来自外部的调试请求，是 Secure 还是 Non-Secure，决定它能访问哪些地址空间。这个机制在普通芯片上感受不到，但在 H563/573 这种带 TrustZone 的芯片上，它会直接影响你能否读 Flash、能否操作内核寄存器。很多人拿到板子后，SWD 能识别到内核，但一读 Flash 就报错，大概率就是卡在这里。
1.2 Debug Port 访问权限：从选项字节到调试认证
H563/573 的调试访问权限控制分为两层。第一层是选项字节（Option Bytes）里的 RDP（Read Out Protection）级别，第二层是 TrustZone 使能后的调试认证机制。
RDP 分三个级别：
- Level 0：无保护，调试器可以完全访问 Flash、SRAM、所有寄存器；
- Level 1：禁止通过调试口读 Flash，但允许连接内核、调试运行中的程序（此时 Flash 内容读出来是 0xFF）；
- Level 2：永久关闭调试口，任何调试访问都被拒绝，而且这个级别的修改是不可逆的。
要注意的是，Level 1 下如果你把 RDP 从 Level 1 降回 Level 0，芯片会自动触发一次性 Flash 全片擦除。这是ST刻意设计的防回退机制，防止有人把芯片开保护后再暴力降级读取内容。所以量产时如果开了 Level 1，每次烧录前都要重新连接并解锁，解锁过程就会擦除 Flash，调试流程要重新规划。
第二层是 TrustZone 的调试认证。当选项字节中的 TZEN 置 1 后，芯片启动后进入 Secure 世界，外部调试器默认只能访问 Non-Secure 区域。如果要调试 Secure 侧代码，必须通过调试认证流程——在连接后发送认证密钥，密钥正确才能获得 Secure 调试权限。H563/573 的认证机制涉及 DBGMCU 的认证寄存器，实际操作时 STM32CubeProgrammer 会引导你输入密钥。
这两层权限控制叠加，就形成了一个矩阵：RDP=0 且 TZEN=0 时，调试体验和普通 MCU 一样；RDP=0 且 TZEN=1 时，需要配置 Secure 调试；RDP=1 时，不管 TZEN 如何，Flash 读取都受限。我见过不少人在 TrustZone 工程里把调试器连上后，程序跑起来了但变量观察窗口全是空的，就是这个矩阵没搞清楚。
2. 四种调试接入方式对比与选型思路
2.1 SWD/JTAG 标准调试：最常用的全功能通道
SWD 是 H563/573 调试的首选，连接 ST-Link、J-Link 或者 DAPLink 都行。接线就四根：SWDIO、SWCLK、GND，另外强烈建议接 NRST（复位引脚）。
我强调一下 NRST 的作用。很多新手觉得 SWD 只需要三根线（数据、时钟、地），但实际调试 H563/573 这种新芯片时，NRST 几乎是必须的。原因是：如果芯片已经进入了低功耗模式、或者 TrustZone 状态不确定、或者程序里把 SWD 引脚重映射了，调试器可以通过复位信号把内核拉回已知状态，再建立调试连接。没有 NRST，遇到这种情况就只能靠硬件复位按键配合“connect under reset”模式碰运气。
J-Link 和 ST-Link 在 H563 上的表现差异不大，但有一个细节：J-Link 的 SWD 速率默认可能跑 4MHz 甚至更高，如果连接线太长、或者目标板电源纹波大，高速率下会出现时连时断的问题。遇到这种情况，先把速率降到 1MHz 以下测试，确认稳定后再逐步提速。
2.2 系统存储器 Bootloader：无调试器时的救急通道
当 SWD 口被禁用、或者调试器不在手边时，H563/573 内置的 ROM Bootloader 是另一个入口。通过把 BOOT0 引脚拉高（或者配置 nBOOT0 选项字节为 1），芯片复位后会进入系统存储器中的 Bootloader，此时可以通过 UART、USB（DFU）、SPI、I2C 等接口接收烧录数据。
这个通道和 Debug Port 的区别在于：它走的是通信外设而非调试接口，所以不涉及 SWD 引脚状态、不涉及 RDP 对调试口的封锁。但要注意，如果 RDP 是 Level 2，Bootloader 同样不可用——这属于出厂级保护，连 ST 官方工具也没有后门。
实际应用中，量产烧录经常用 UART Bootloader，因为产线设备不需要安装调试器驱动，一条 USB 转串口线就能搞定。缺点是速度慢，H563 的 UART Bootloader 跑 115200 波特率时，烧一个 2MB 的固件要几分钟，比 SWD 慢一个数量级。
2.3 USB DFU 与调试通道的关系
H563/573 支持 USB DFU（Device Firmware Upgrade），这是另一种不需要调试器的烧录方式。但很多人没意识到，DFU 本质上走的是 USB 外设，和 Debug Port 是两条完全独立的路径。DFU 的优势是速度快、操作简单（CubeProgrammer 直接通过 USB 连接），缺点是它要求芯片能进入 DFU 模式——通常也是通过 BOOT 引脚或者运行一个 DFU 应用程序来实现。
在调试开发板时，我通常把 DFU 当作 SWD 之外的备用方案。比如 SWD 引脚被复用成其他功能、又不想焊线的情况下，用 DFU 烧一个禁用引脚的固件进去，再回到 SWD 调试。这个“绕一圈”的思路在硬件调试中很实用。
2.4 调试端口禁用与恢复的完整路径
调试端口可以被软件禁用吗？可以，有两种情况。第一种是选项字节中的 DBG_LOCK 相关的安全配置（主要在 TrustZone 场景下用），第二种是直接在程序里把 SWD 引脚配置成普通 GPIO。
第二种情况更常见，而且经常是“无意中”发生的。比如你在初始化代码里把 PA13/PA14 配成了其他复用功能，下次连接调试器时就找不到内核了。恢复方法有两种：拉高 BOOT0 进入 Bootloader，用 STM32CubeProgrammer 擦除 Flash；或者用“connect under reset”模式，在复位瞬间抓住调试口，此时引脚还是默认的调试功能。
这里插一句经验：在设计产品时，如果 SWD 引脚有被复用的需求，我建议在代码里加一个“调试口锁定延时”，就是上电后前几百毫秒保持调试引脚功能，如果有调试器连接则进入调试模式，否则再切换成 GPIO。这样既能保留调试能力，又能让出引脚给应用功能，是不少带屏产品的常用做法。
3. 实操：从硬件连接到成功识别 H563/573 的关键步骤
3.1 硬件接线与目标板准备
先列一个标准的 SWD 连接关系表，适用于 ST-Link V2/V3、J-Link、DAPLink：
| 调试器端 | STM32H563/573 端 | 说明 |
|---|---|---|
| SWDIO | PA13 | 数据线，双向 |
| SWCLK | PA14 | 时钟线，由调试器驱动 |
| NRST | NRST | 复位，强烈建议接 |
| SWO（可选） | PB3 | 串行跟踪输出，用于 ITM 调试 |
| GND | GND | 共地，必须接 |
| VTref / 3.3V | VDD（3.3V） | 电平参考，注意别接错 |
关于供电，ST-Link 的 VTref 引脚是用来检测目标板电平的参考输入，不是给目标板供电的。调试 H563 时，目标板通常自己供电，ST-Link 只接 GND 和信号线。如果你要用 ST-Link 给板子供电，走的是 3.3V/5V 引脚，电流不大，只适合低功耗项目验证用。
H563/573 有个和其他 MCU 不太一样的地方：供电方案有 LDO 和 SMPS 两种，内置 SMPS 时 VCAP 引脚要接储能电感。如果硬件设计用的是 SMPS 供电，调试器连接时电源纹波会大一些，SWD 速率就不能跑太高，否则可能出现时钟沿抖动导致通信失败。遇到这种情况，把 SWD 频率从 4MHz 降到 1MHz 或 800kHz 再试。
3.2 用 STM32CubeProgrammer 连接：两种模式与核心命令
连接 H563/573 推荐用 STM32CubeProgrammer，ST 官方提供的烧录调试工具，命令行和 GUI 都有。GUI 操作直接选 ST-LINK 和 SWD 模式，点 Connect 就行，但命令行方式更适合批量化和自动化场景。
最基本的连接命令：
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG这里 mode=HOTPLUG 表示热插拔模式，也就是调试器直接连接、不自动复位目标芯片。如果你的芯片程序已经跑飞或者进入了异常状态，用复位连接模式更可靠：
STM32_Programmer_CLI -c port=SWD mode=UNDER_RESET这种模式会拉低 NRST，让芯片保持复位状态，然后初始化调试口，最后释放复位。它能绕过很多“连接不上”的问题。
连接成功后，读取芯片信息：
STM32_Programmer_CLI -c port=SWD mode=UNDER_RESET -r16这行命令会读取 16 字节的芯片标识信息，包括 Device ID（H563 是 0x495，H573 是 0x497）和 Flash 大小等。看到这些信息，说明 Debug Port 链路是通的。
读取选项字节确认当前安全状态：
STM32_Programmer_CLI -c port=SWD mode=UNDER_RESET -ob输出里重点看两个字段：RDP 级别和 TZEN 状态。如果 RDP=0xAA 表示 Level 0，RDP=0xBB 表示 Level 1，RDP=0xCC 表示 Level 2。TZEN=1 表示 TrustZone 已使能。
3.3 TrustZone 开启后的调试访问处理
如果你拿到的板子已经开启了 TrustZone，直接连接后可能发现很多操作受限。这时候需要进入 TrustZone 调试流程。
在 STM32CubeProgrammer 的 GUI 界面中，连接后会弹出一个对话框询问你是否要执行 Debug Authentication。选择执行后，输入调试认证密钥（这个密钥在 TrustZone 工程生成时由用户配置），才能获得 Secure 侧调试权限。
命令行方式也支持认证参数。举例（具体命令参数版本略有差异，以实际工具版本帮助为准）：
STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -da password=0x12345678 address=0x0认证成功后，调试器就能访问 Secure 地址空间了。但我提醒一点：Debug Authentication 密钥如果丢失，那 Secure 侧数据就永远访问不了了。这和安全启动密钥一样，属于需要离线保存的关键资产。
另外，如果只是想用 SWD 烧写 Non-Secure 固件，其实不一定要认证。Non-Secure 区域在 TZEN=1 时默认可访问，只是 TrustZone 使能后，Flash 的地址空间被划分成了 Secure 和 Non-Secure 两块，烧写时要确认目标地址落在哪块区域。
3.4 擦除、烧录、校验的完整命令链
调试口连上之后，最常用的几个操作我列出来：
擦除整片 Flash：
STM32_Programmer_CLI -c port=SWD mode=UNDER_RESET -e all下载固件并校验：
STM32_Programmer_CLI -c port=SWD mode=UNDER_RESET -w firmware.hex -v如果固件是 bin 格式，需要指定起始地址，H563 的 Flash 基地址是 0x08000000：
STM32_Programmer_CLI -c port=SWD mode=UNDER_RESET -w firmware.bin 0x08000000 -v这里 -v 参数是烧录后自动校验，量产时务必加上，防止烧录过程异常导致坏板流出。实际量产中我发现，如果 USB 供电不稳，烧录过程中 SWD 通信偶发中断，没有校验的话坏板根本发现不了。
如果 RDP 是 Level 1 状态，需要先解除保护（注意会触发全片擦除）：
STM32_Programmer_CLI -c port=SWD mode=UNDER_RESET -ob RDP=0xAA执行后芯片会自动擦除所有 Flash 并回到 Level 0，相当于恢复出厂状态。
4. 常见问题与排查实录：调试口接不通的解决思路
4.1 连接失败：从硬件到软件的逐层排查法
Debug Port 连接失败是 H563 开发中最常见的问题，我按排查顺序列一个清单：
- 首先检查接线：SWDIO 和 SWCLK 是否接反、GND 是否共地。我见过太多人把 SWDIO 和 SWCLK 对调了，然后花一小时怀疑固件有问题。
- 检查供电：VDD 电压是否稳定、是否有足够的电流。H563 在调试连接瞬间会有电流波动，供电不足会导致调试口初始化失败。
- 检查复位引脚：NRST 是否被外部电路强制拉低。如果复位引脚被拉低，调试器永远无法建立连接。
- 检查 SWD 速率：降低到 800kHz 或 1MHz 试试。电路板布局不好或者杜邦线太长时，高速率下容易失败。
- 检查选项字节：用 Bootloader 方式连接到芯片，读取 RDP 和 TZEN。如果 RDP=Level 2，那就没有办法了，只能换芯片。
- 检查程序里的引脚复用：如果代码配置了 PA13/PA14 为其他功能，需要进入“connect under reset”模式并擦除 Flash。
这里有一个实际案例。之前调一块 H563 板子，SWD 连接一直是“No ST-Link detected”，但 ST-Link 本身是好的（在另一块板上测过）。最后排查发现是 ST-Link 和 PC 之间的 USB 线质量差，换了一根带屏蔽的 USB 线就好了。这种问题最恶心，因为现象表现为调试器检测不到，但实际上是 USB 物理链路不稳定。
4.2 RDP 与 TrustZone 引发的“幽灵”问题
还有一种情况：调试器能连接上，芯片 ID 也能读出来，但一读 Flash 就报错，或者程序烧录进去后运行异常。这种通常是 RDP 或 TrustZone 的锅。
RDP=Level 1 时，通过调试口读取 Flash 会被硬件屏蔽，读出数据全是 0xFF。从表面看，烧录似乎成功了（写操作不被阻止），但读回校验必然失败。如果你在量产流程里开了 Level 1，烧录时要用特殊方式处理——先解除保护烧录，再重新开保护。
TrustZone 的问题则更隐蔽。当 TZEN=1 时，Flash 被划分为 Secure 和 Non-Secure 区域，Secure 区域在调试认证前对调试器是不可见的。如果你烧录了一个 Non-Secure 程序到 Secure 区域地址（0x0C000000 开始），程序可能启动不了，因为 Secure 侧代码被调试验证拦住了。
这类问题排查思路是这样的：先用-ob查看选项字节，确认 TZEN 和 RDP 状态；然后尝试 Debug Authentication；最后才是怀疑代码问题。不要一上来就重新编译工程，先确认芯片本身的调试访问状态。
4.3 低功耗模式下的调试：DBGMCU 寄存器的作用
H563/573 在进入 Stop、Standby 等低功耗模式后，默认会切断内核时钟，调试器自然就断了。但 ST 在设计芯片时留了一个后门：DBGMCU 寄存器组中的调试控制位，可以让内核时钟在低功耗模式下继续运行，从而维持调试连接。
具体来说，通过调试口写入 DBGMCU_CR 寄存器，设置 DBG_SLEEP、DBG_STOP、DBG_STANDBY 位。在 STM32CubeProgrammer 的 GUI 中，也可以找到对应的低功耗调试选项。
这个功能在调试低功耗应用时极其有用。比如你在调试一个电池供电的设备，想观察它进入 Stop 模式后的电流波形，同时又要看代码是否执行到某一行，就需要启用 STOP 模式的调试时钟。不启用的话，进入 Stop 模式后调试器就掉线了，根本无法单步观察。
实际使用中注意：启用低功耗调试后，芯片的功耗会明显上升，因为内核时钟还在跑。测量低功耗电流时，必须关闭这些调试位，否则测出来的电流是虚假的。
4.4 常见问题速查表
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| 提示 No ST-Link detected | USB 线问题/ST-Link 固件问题 | 换线、更新 ST-Link 固件 |
| 检不到目标芯片 | SWD 引脚接反/供电问题 | 检查接线、电压、复位状态 |
| 能读 ID 但读 Flash 报错 | RDP=Level 1 | 解除保护或处理校验方式 |
| 连接后崩溃或死机 | SWD 速率过高 | 降到 1MHz 以下 |
| 变量观察窗口无数据 | TrustZone 未认证 | 执行 Debug Authentication |
| 进入低功耗后调试断开 | DBGMCU 未配置 | 设置低功耗调试控制位 |
| 程序跑飞后连不上 | 引脚被复用为 GPIO | connect under reset 模式擦除 |
| 烧录后校验失败 | Flash 写入保护/地址错误 | 检查 WRPin、地址范围 |
5. 一些调试认证的进阶注意事项
5.1 Debug Authentication 密钥体系
前面提到了 Debug Authentication，这里展开说说。H563/573 的调试认证基于一组椭圆曲线密钥对，在激活 TrustZone 和设置调试认证时生成。生成私钥（Debug Authentication private key）后，调试器需要持有这把私钥才能完成 Secure 侧认证。
在 STM32CubeMX 里可以通过 TrustZone 配置界面生成调试认证证书，同时会输出一个 .pem 格式的私钥文件。这个文件务必离线保存，不要提交到 Git 仓库。我在项目中专门有一个受控的密钥目录存放这类文件，权限只开放给核心的开发工程师。
如果 Debug Authentication 私钥丢失，但芯片已经锁定了 Secure 区域，唯一的出路是：
- 如果 RDP 还没到 Level 2，通过降低 RDP 级别触发全片擦除，所有数据丢失；
- 如果 RDP=Level 2，芯片直接报废。
所以在量产阶段严格评估是否真的需要开启 Level 2 保护，毕竟一旦开启，产线不良品也没法通过调试口分析了。
5.2 同时使用 SWD 和 BOOT 引脚的启动逻辑
H563/573 复位后从哪里启动，由 BOOT0 引脚和选项字节 nBOOT0 共同决定：
- nBOOT0=1（默认）且 BOOT0 引脚为低：从主 Flash 启动；
- BOOT0 引脚为高：从系统存储器 Bootloader 启动；
- nBOOT0=0：直接从系统存储器启动，不管引脚状态。
在调试场景中，BOOT 引脚状态会影响你“能不能连上”。如果要从 Bootloader 启动恢复调试口，就把 BOOT0 拉高，复位芯片，然后用 STM32CubeProgrammer 的 UART 或 USB 模式连接，执行全片擦除后再把 BOOT0 拉低复位。
这里有一个细节：如果用串口 Bootloader 连接，ST 的 Bootloader 协议默认会等待 100ms 左右的主机握手信号，如果你用 CubeProgrammer 连接，它会自动处理这个时序。但如果自己写脚本控制串口，必须在复位后的几毫秒内发送 0x7F 握手字节，否则 Bootloader 会超时退出，需要重新复位再次尝试。
5.3 解锁后的安全习惯
调试接口是开发时最方便的入口，也是攻击者最常盯上的入口。在开发阶段保持 RDP=Level 0 没问题，但产品发布前，我建议至少把 RDP 升到 Level 1。这样即使设备丢失，也无法通过调试口抠出固件，保护你的代码心血。
但注意，RDP=Level 1 也会带来一些调试上的麻烦。例如你在做现场问题分析时，如果设备是 Level 1 保护的，你可以连接调试器进行实时调试（观察运行状态），但不能读取 Flash 内容。这时候要分析崩溃现场，主要靠 RAM 里的调试信息、RTOS 的断言信息还有 SWO 输出的日志。
6. 实操后的几点经验沉淀
Debug Port 访问这件事，说到底是和安全体系绑定在一起的。H563/573 作为带 TrustZone 的高性能 MCU，它的调试接口设计比传统 MCU 复杂，但本质逻辑是一致的——先把芯片状态搞清楚，再决定如何连、连了之后能做什么。
我个人的几个建议：
第一，任何一块新板子，上电后用 CubeProgrammer 读一次芯片 ID 和选项字节，这是在硬件调试器介入之前确认“芯片活着”的最快方式。这一步能帮你排除大量低级问题。
第二，SWD 连接时 NRST 一定要接。表面上省一根线省不了多少事，但一旦遇到死机状态，没有 NRST 就没法复位进入调试模式，损失的时间远大于接线的成本。
第三，遇到连不上的情况，先降速、再查线、最后查代码。这个顺序能解决 80% 的连接失败问题。不要一上来就怀疑芯片坏了，H563 的硬件质量在 H5 系列里是相当稳的。
第四，如果你在用 TrustZone，尽早建立 Debug Authentication 密钥的流程化管理。密钥文件放在什么地方、谁有权访问、如何备份，这些都要提前定好，否则项目后期一定会在这里卡壳。
调试口是嵌入式开发的窗口，把它彻底摸透了，项目推进会顺畅很多。这篇文章基本覆盖了 H563/573 Debug Port 访问的关键路径和坑点，按这个思路操作，基本不会在调试接入这一关被卡住太久。
