4. 调试接口与协议
在RISC-V裸机调试中，调试主机（PC上的GDB/OpenOCD）并不能直接读写CPU寄存器或内存，它必须借助一条物理调试链路，把“读寄存器”“写内存”“设置断点”等请求翻译成芯片内部可执行的调试事务。理解JTAG、cJTAG、SWD这些接口协议，以及RISC-V Debug Specification定义的DM（Debug Module）与DMI（Debug Module Interface）模型，是排查“连不上目标”“halt失败”“断点不生效”等问题的前提。
一、物理层与协议层：JTAG、cJTAG、SWD的定位
JTAG（IEEE 1149.1）是最经典的边界扫描与调试接口，使用TCK、TMS、TDI、TDO四根信号（外加可选的TRST），通过TAP状态机串行移位。它的优点是标准化程度高、几乎所有SoC都保留；缺点是引脚多、时序状态机复杂。cJTAG（IEEE 1149.7）是JTAG的紧凑扩展，典型两线模式只用TCK与TMS（TDI/TDO复用），适合引脚紧张的封装。SWD是ARM定义的串行调试接口，仅需SWCLK与SWDIO两根线，协议更精简，但它是ARM生态的私有接口，RISC-V芯片通常不采用。
需要特别澄清一个常见误区：SWD不是RISC-V的标准调试接口。RISC-V Debug Specification把物理传输层抽象为DTM（Debug Transport Module），JTAG只是其中一种被广泛实现的DTM。因此看到“RISC-V + SWD”的组合，通常意味着该芯片内部集成了ARM核或使用了桥接方案，而不是RISC-V调试规范本身的要求。
二、RISC-V Debug Specification的分层模型
RISC-V调试规范采用清晰的分层结构，从外到内依次是：调试主机 → 调试探针（如FT2232、J-Link、CMSIS-DAP） → DTM → DMI → DM → 目标hart。其中DTM负责物理链路与协议转换，DM是调试功能的核心状态机，DMI是DTM与DM之间的寄存器访问接口。
DM内部包含一组可被DMI访问的寄存器，例如dmcontrol、dmstatus、abstractcs、data0、command、hartinfo等。调试主机通过写command寄存器发起抽象命令（读GPR、写GPR、访问内存），通过轮询abstractcs.busy判断完成，再从data0取回结果。这套“命令-状态-数据”的寄存器模型，是理解所有RISC-V调试操作的主线。
三、DM与DMI的工作流程
以“读取hart的x1寄存器”为例，典型流程如下：
- 调试主机通过探针向DTM发送DMI写事务，把
command寄存器设置为“读GPR x1”的抽象命令编码。 - DM收到命令后置位
abstractcs.busy，并驱动hart进入调试模式执行该操作。 - 主机轮询
abstractcs，直到busy清零；若cmderr非零，说明命令执行出错。 - 主机通过DMI读事务读取
data0，得到x1的值。
这个过程可以用OpenOCD日志直观看到。当连接失败时，日志往往停在“Examining RISC-V target”或反复打印DMI超时：
Info : RISC-V: Connecting to target...
Info : datacount=2 progbufsize=8
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=32, misa=0x40101104
Error: Debug Module did not become ready after 1000 ms
Error: dmi_read(): failed to read dmstatus
这类日志说明DMI层通信已经建立，但DM没有进入就绪状态，常见原因是复位未释放、时钟未使能、DM被安全策略锁定，或hart处于不可调试的低功耗状态。
四、常见接口与协议对比
| 接口/协议 | 信号线 | 所属生态 | 在RISC-V调试中的角色 |
|---|---|---|---|
| JTAG | TCK/TMS/TDI/TDO | IEEE 1149.1 | 最常用的DTM物理层 |
| cJTAG | TCK/TMS（两线） | IEEE 1149.7 | 引脚受限场景下的JTAG压缩 |
| SWD | SWCLK/SWDIO | ARM私有 | 非RISC-V标准，需桥接或ARM核 |
| DMI | 逻辑接口 | RISC-V Debug Spec | DTM与DM之间的寄存器访问通道 |
| DM | 逻辑模块 | RISC-V Debug Spec | 执行抽象命令、控制hart |
五、案例与排障复盘
某RISC-V开发板使用FT2232作为JTAG探针，OpenOCD配置为adapter speed 1000。现象是偶尔能识别hart，但执行halt时随机失败。排查发现：JTAG时钟在1 MHz下信号完整性尚可，但目标板JTAG走线较长且未做阻抗匹配，TCK上升沿出现振铃，导致TAP状态机偶发误跳转。将adapter speed降到200 kHz后稳定。这说明物理层信号质量会直接表现为DMI事务失败，而日志只会显示“DM not ready”，容易误导为DM配置问题。
abstractcs.cmderr而只看busy。这些都会导致定位方向错误。
掌握“主机→探针→DTM→DMI→DM→hart”这条链路，以及DM寄存器“命令-状态-数据”的访问模型，就能把大多数连接与halt类故障拆解到具体层级，而不是停留在“调试器连不上”的模糊描述上。