WhyCan Forum(哇酷开发者社区)

关注一下，看看最终还有几根头发

 关注

关注一下。要是以后gd32没有芯片用了，就做一版ch552版本的gdlink。这事情伤害不大，侮辱性比较强。

大概不会，因为JTAG/SWD都是串行协议，速度能到几十Mbps就不错了。USB 3.0应该更适合trace的用途。

关注一下,现在CH的芯片也缺货了.

强帖，最新进展有没？

最近想用CH552实现一个usb-blaster，掉坑里了。

欢迎探讨
开源CH551/2实现的汇编优化高速DAP-Link (CMSIS-DAP v2)
https://whycan.com/t_7786.html

协议层

协议层关心的主要是所谓“数据包”的收发，也就是调试协议每次传输的最小单位。
一般而言，协议层的数据传递需要依靠收发双方各自维护一个状态机，引脚的状态变化会使得这个状态机不断更新到下一个状态，直到停留到目的状态，收发双方获取到所需的信息为止（传输错误等也可以看作是一种信息）。
需要说明的是，协议层一般只维护基本的传输功能，并不对收发的数据进行进一步分析，这些分析操作应该交由上层（数据链路层和AP层）完成。

SWD

SWD作为两线协议，传输数据的过程必然需要协商好数据传输的方向，否则可能会导致信号冲突或者握手失败。好在SWD的协议并不复杂，下面我们来一窥端倪。

传输格式

SWD的数据包可以分为以下三个主要部分：

• Packet request：表示调试器的命令，传输方向为从调试器到DP

• Acknowledge response：表示DP对请求的响应，传输方向为从DP到调试器

• Data transfer phase：表示实际传输的数据，传输方向根据命令确定

另外，在切换传输方向时，需要数个周期的时间，这个阶段被称为turnaround。一次正常的传输总会包括两次turnaround，原因是packet request和acknowledge response的传输方向总是相反的。

接下来我们看各个部分的格式。

对于packet request，共有8个bit，按传输顺序分别如下（均为小端序，下同）：

• Start：表示开始发送，恒为0b1

• APnDP：表示传输的寄存器，0b0为DP，0b1为AP

• RnW：表示数据的传输方向，0b0为调试器写（DP读），0b1为调试器读（DP写）

• A[2:3]：表示寄存器的索引

• Parity：表示APnDP到A[3]这4个bit的偶校验结果（其实就是将这4个bit异或后得到1个bit的结果）

• Stop：表示结束发送，恒为0b0

• Park：将SWDIO置为高电平，以便后续turnaround保持高电平状态（通过上拉电阻）

对于Acknowledge response，共有3个bit，其中：

• 0b100：OK，表示读写操作正常发起

• 0b010：WAIT，表示当前DP正忙，需要调试器重试，或是（在重试一定次数后）使用ABORT寄存器终止传输

• 0b001：FAULT，表示之前的传输有误，需要调试器读取相应寄存器获取出错原因

• 其它：表示可能出现其它错误，包括协议错误（protocol error）或是与DP断开连接等，由于packet request阶段结束时已经将SWDIO设为高电平，因此最有可能出现的是0b111，表示DP没有驱动SWDIO

对于Data transfer phase，共有33个bit，传输方向由Packet request中的RnW确定，其中：

• 前32个bit表示传输的数据

• 最后1个bit表示前32个bit的偶校验结果

从上面可以看出，一个数据包的长度为(Read) 8 + Trn + 3 + 33 + Trn = (Write) 8 + Trn + 3 + Trn + 33 = 44 + 2 * Trn，其中Trn表示turnaround的时钟周期数。

读写方式和错误处理

在明确传输格式后，接下来就可以让调试器和DP开始沟通了。不过，一次完整的传输需要考虑的事情可不少：

• DP和AP寄存器的读写方式有所不同。由于AP寄存器的访问需要时间，因此相对于DP寄存器而言等待时间可能更长，并且可能出现的状况也更多。

• 在acknowledge response返回不同值的时候，需要有不同的处理方法。成功的时候自然是最好，如果遇到了其它状况，也应该妥善处理，以保证调试器和DP能够正常工作。

我们先来说写寄存器的情况。在成功写寄存器时，波形图如图B4-1所示。

可以看到，在acknowledge response阶段，DP通过返回OK表明自己有能力接收新的数据。至于此次传输的数据是否被DP成功接收，则需要等待下一次传输的acknowledge response返回，其中：

• 若写的是DP寄存器，则通常可以直接获知是否成功传输，也就是说会在下一次传输时返回OK/FAULT或其它错误

• 若写的是AP寄存器，则由于可能需要等待上次传输完毕，可能需要等待一段时间才能获知传输是否成功，也就是说下一次传输时可能会返回WAIT，直到上次传输完毕

接下来是读寄存器的情况。在成功读寄存器时，波形图如图B4-2所示。

这里需要区分读DP寄存器和读AP寄存器的情况了。对于读DP寄存器，这种情况比较简单，只需要一次传输就能获取到acknowledge response和所需的状态；与之相对应的是，读AP寄存器需要考虑AP寄存器的延迟，需要两次传输才能获取到实际的数据。

读AP寄存器的流程如下：

1. 第一次传输，需要在packet request指明传输的AP寄存器；在acknowledge response阶段，DP通过返回OK表明自己有能力处理此次请求；此时传输的数据内容无意义，应当丢弃。

2. 第二次传输，需要在packet request指明读取DP寄存器中的RDBUFF寄存器；在acknowledge response阶段，DP通过返回OK表明自己已经从AP获取到新的数据并准备好回传给调试器；此时传输的数据即为所需的内容。如果数据没有准备好，DP会返回WAIT，需要重复第二次传输直到DP返回OK为止。

可以看到，读AP寄存器实际上需要分为先提交后接收的两个步骤。当然，如果需要多次读取AP寄存器，则提交和接收可以在同一次传输中交替完成（在ADIv6中被称为流水线化），即：

1. 首先发起第1个AP寄存器的读取，并且丢弃此时返回的数据。

2. 接下来发起第2个AP寄存器的读取，等待acknowledge response返回OK，此时返回的数据即为第1个AP寄存器的结果。

3. 重复2的步骤，每次发起第n个寄存器的读取时，都会返回第(n-1)个寄存器的结果。

4. 在所有AP寄存器均发起读取后，需要再额外发起一次传输，读取DP寄存器中的RDBUFF寄存器，以获取最后一次传输的结果。

到这里为止，我们就把成功传输时的处理方式介绍完了。但是，调试器的传输过程不可能做到尽善尽美，那么在遇到意外状况时，应该怎么处理呢？这里我们按照错误类型进行介绍：

• WAIT：一般表示上一次读写AP寄存器的操作还未结束，这种情况下常规操作是继续发起相同的传输，直到响应OK为止；当然也可以通过ABORT寄存器终止传输，这个会在后续数据链路层中介绍。

• FAULT：技术上说，返回FAULT表示的是CTRL/STAT寄存器有sticky flag被设为0b1，而这通常表示DP发现了一些错误，包括写寄存器时data packet phase的校验位出错等，感兴趣的读者可以参考数据链路层部分。

• Protocol error：包含了一系列不符合传输协议的错误，例如packet request中的校验位出错、Stop和Park出错、不支持的turnaround周期数等。

大家可能会有些疑惑，为啥还没有看到错误发生时的波形图呢？这是因为，WAIT和FAULT时的波形与overrun detection有关。Overrun detection是DP的一个特性，针对调试器在高可靠性、高延迟、高吞吐量的场合使用，可以有效加快处理效率。当然，我们这里主要说明的还是打开和关闭overrun detection的不同之处。

在关闭overrun detection时，如果DP返回WAIT或FAULT，则跳过接下来的data transfer phase，直接开始下次传输，如下图B4-3和B4-4所示。

但是，如果打开overrun detection，不论DP返回WAIT还是FAULT，接下来的data transfer phase都和成功传输一样进行，只是传输的数据无效，如图B4-6和B-7所示。

最后说说Protocol error。一般来说，protocol error的错误是比较严重的，通常意味着信号传输不稳定，导致调试器或DP读取到了错误的结果。这种情况下，DP的策略是比较保守的，一般是直接终止所有传输（除特定寄存器外），调试器需要尽快发起line reset以重置DP状态；因此，DP将会在检测到错误后释放对SWDIO的驱动，在调试器一端通常会读到0b111的响应，如下图B4-5所示。

对于protocol error，详细的处理方式可以参考ADIv6中的B4.2.5，这里不再赘述。

其它细节

从上面我们知道，SW-DP是有状态的，读写结果会和之前的传输有关，因此恢复到初始状态显得非常重要。

在ADIv6中，SWD有个名为line reset的特性，就是在必要的时候对SW-DP进行重置，以保证SW-DP能工作在确定的状态，这个特性会在以下场景使用：

• SW-DP初始化：在首次连接到SW-DP时，需要在传输前先来一发line reset，以保证SW-DP不会受到上电时不定态或已传输数据的影响。

• 切换DP：无论是从JTAG-DP切换到SW-DP，还是从其它SW-DP切换过来，也都需要一次line reset。

• 错误恢复：前面提到的protocol error需要通过一次line reset才能恢复。

那么，line reset要怎么做到呢？其实很简单，就是传输以下序列即可：

1. 首先，给至少50个周期的SWDIO高电平，此时SW-DP可以识别到line reset。

2. 紧接着给至少2个周期的SWDIO低电平，让SW-DP做好准备。

3. 最后正常传输即可。

Line reset的波形图如图B4-8所示。

可以看到，2的话并不影响结果，这实际上是SW-DP的一个特性：空闲周期（idle cycles）。回想起每次传输的Start信号为0b1，如果在此时传输的是0b0，则传输不会开始，SW-DP可以维持在空闲状态，等待SWDIO传输0b1后传输才正式开始。

JTAG-DP

对于JTAG，想必大家都不陌生（陌生的建议先看看IEEE Std 1149.1，逃），在其它器件上已经使用过。由于JTAG的引脚都是单向传输的（到了1149.7才有两线调试的方案，才会涉及到引脚传输方向切换），并且JTAG在协议层本质上就是一个状态机（见图B3-2），因此说明起来会比较容易。这里就尽量简明扼要地描述其中需要关注的部分。

传输格式

JTAG-DP和普通的JTAG状态机的用法基本一致，都是分为指令寄存器（Instruction Register，即IR）和数据寄存器（Data Register，即DR）。对于JTAG而言，一般是有一个IR和多个DR，其中：

• IR用于选择和控制JTAG扫描链，位数是固定的

• DR用于交换暴露在JTAG扫描链的信息，具体的信息一般由IR决定，位数是可变的

因此，一次传输需要先选择IR再向DR写数据同时读返回结果。具体的传输过程在B3.2.3中已有详细描述，这里不再赘述。

读写方式和错误处理

从ADIv6的表B3-3中，我们可以获知，标准IR指令如下：

• ABORT

• DPACC

• APACC

• IDCODE

• BYPASS

其中，IDCODE和BYPASS是JTAG标准要求的部分，DPACC和APACC基本对应SW-DP中的DP和AP寄存器，而ABORT则是单独列出。后面主要提到DPACC和APACC部分。

DPACC和APACC的操作如B3.4.3的图所示。可以看到，这两个DR都是35位，数据结构如下：

• 对于TDO这一端，JTAG依次输出ACK[0:2]和ReadResult[0:31]

• 对于TDI这一端，JTAG依次输入RnW、A[2:3]和DATAIN[0:31]

相对于SW-DP，由于JTAG-DP的Capture-DR在Update-DR之前执行，而JTAG-DP的acknowledge response和ReadResult在Capture-DR阶段确定、packet request和DATAIN在Update-DR阶段生效，因此当前传输的数据包需要在下一次传输时给出。当然，和SW-DP中读AP寄存器类似，JTAG-DP也可以通过流水线执行的方式“重叠”这些命令，执行过程如下：

1. 首先发起第1个寄存器的传输，并且丢弃此时返回的acknowledge response和ReadResult。

2. 接下来发起第2个寄存器的传输，并且从acknowledge response的结果获知传输是否成功，如果第1个寄存器对应的传输是读取，则还需同时读取ReadResult并作为第1个寄存器的读取结果，否则直接丢弃。

3. 重复2的步骤，每次发起第n个寄存器的传输时，都会返回第(n-1)个寄存器的acknowledge response，并根据需要判断是否需要读取ReadResult。

4. 在所有寄存器均发起传输后，需要再额外发起一次传输，读取DPACC中的RDBUFF寄存器，以获取最后一次传输的acknowledge response。如果第n个寄存器对应的传输是读取，则还需同时读取ReadResult并作为第1个寄存器的读取结果，否则直接丢弃。

这里有一些需要注意的细节：

• 由于JTAG-DP对所有指令的写入和读取都是流水线化的，因此要确保此次传输被成功接受，就必须发起下一条指令来读取结果。可以通过读取DPACC寄存器的RDBUFF寄存器来获取acknowledge response，这是因为读取RDBUFF寄存器总是不会产生其它副作用。

• 当返回的结果为WAIT，或者有sticky flag为0b1时，此次传输将被丢弃，因此可以仅通过读取TDO输出的前3位（即ACK[0:2]）来判断上一次传输是否成功进行，若非成功进行则可以直接结束传输。

• JTAG-DP返回的ReadResult仅在上一个传输访问的是DPACC、APACC和BYPASS这三个DR时才有意义，因此不能在执行DPACC和APACC的传输过程中切换到其它DR。

另外，JTAG-DP在协议版本不同的时候acknowledge response的定义会有所不同，见表B3-6。在v0中，OK和FAULT合并为一个，即OK/FAULT，对应的ACK[2:0]为0b010，是否传输成功需要读取CTRL/STAT寄存器才能获知；而v1中，又将OK和FAULT分离。

其它细节

在Capture-IR阶段，JTAG扫描链会写入0b0001或0b00000001（取决于IR长度为4位或8位），并且最靠近TDO的是0b1，这个可以在后续更新IR时被移出，用来检查扫描链的连接是否正常。

和SW-DP类似，JTAG-DP也有自己的idle cycles，不过这一定义借用了JTAG状态机中的Run-Test/Idle状态。除了和SW-DP类似用于减少实际执行时间的作用外，如果host需要在传输结束后停止TCK，需要保证在Update-DR后至少在Run-Test/Idle状态转8个周期，以保证传输结束（当然如果继续使用JTAG或者不需要最后一次传输结果时则不受此影响）。

JTAG-DP和SW-DP的一大不同是没有line reset，这意味着JTAG-DP不能（其实也不需要）将传输恢复到初始状态。从ADIv6中，我们知道，JTAG-DP仅能在上电复位时重置DP寄存器，但是JTAG-DP不需要像SW-DP那样设置turnaround，因此初始化对于JTAG-DP来说只需要重新设置一遍寄存器就好，不会和当前的状态冲突。

SWJ-DP

在协议层，SWJ-DP主要做的事情就是处理SW-DP和JTAG-DP之间的切换。根据SWD协议版本不同，SWJ-DP最多有两套切换方式，分别是：

• SWD和JTAG之间的切换

• 休眠状态和相关操作

接下来详细介绍这两种切换方式。

SWD和JTAG之间的切换

这种方式多用于SWD协议v1，v2也可以支持但被废弃（deprecated）。

先贴个状态转移图，见图B5-1。

从图上可以看出：

• SWJ-DP的初始状态为JTAG-Sel TLR，也就是JTAG状态机中的Test-Logic-Reset状态

• SWD和JTAG之间的切换需要在特定的状态完成，成功的话会切换到相应状态，失败的话则会保持在原有状态

当然，实际应用中，我们只需要使用JTAG-to-SWD和SWD-to-JTAG这两种序列就可以了。这部分是ARM规定好的，因此没啥好说的，照做就是了。

JTAG-to-SWD的引脚时序如图B5-2所示。

SWD-to-JTAG的引脚时序如图B5-3所示。

休眠状态和相关操作

SWD协议v2引入了休眠状态（dormant state），所有的切换操作都需要途径dormant state状态进行，这有助于目标设备使用不同的混合协议。

在引入休眠状态后，SWJ-DP的协议选择如图B5-4所示，注意到前面提到的JTAG-to-SWD和SWD-to-JTAG已被废弃。

对于SW-DP，相关状态转移图中JTAG相关状态被移除，且初始状态即为dormant state，如图B5-5所示。

JTAG-to-DS涉及到ZBS（zero-bit-DR-scan）序列，并没有统一的引脚时序，其中一个推荐的引脚时序如图B5-7。需要注意的是，这里需要事先将IR切换到IDCODE或BYPASS，否则行为无法预测。对ZBS有兴趣的同学可以参考B5.3.2。

SWD-to-DS则是固定序列，引脚时序如图B5-8所示。

从dormant state离开时，根据activation code确定下一个使用的协议，相关序列被称为Selection Alert sequence（这里不知道怎么翻译比较好），如图B5-9所示。Activation code的取值如表B5-2所示。

最近编辑记录 metro (2022-06-05 15:24:22)

@llinjupt

感谢回复。这部分内容是JTAG规范提到的，我理解是否接上下拉电阻应该取决于具体的硬件设计，如果硬件厂商或者IP核厂商不建议这么搞，一般是有硬件上的一些考量，这个时候应该优先遵循这些规则（毕竟JTAG规范只是建议而不是强制）。

最近编辑记录 metro (2022-06-09 01:48:14)

硬件八字还没一撇呢，目前都是理论研究😅

楼主 用CH549是不是好一些

好久不见，距离上次更新又过去了近两年时间。这几年时间单片机的价格大跳水，1块钱带USB的单片机已经不再是传说，是时候重启这个项目了。

在主控芯片的选择上，当初我们基本上只有CH552能选，而现在STC8H2K08U或者CH32X033都是更好的选择，两者的散片价格都在1块钱左右。考虑到开发难度和后续的升级能力，后者都是更好的选择，因此后续我们将用RISC-V核心的CH32X033来完成——虽然和标题有些冲突，但我们的目标是花最少的钱实现同价位最高的性能。

CH32X033的纸面数据还是可以的，至少从存储器来看是管够的，这意味着我们很容易就能移植现成的CMSIS-DAP甚至DAPLink并让它跑起来，但是这样的性能可能不够极致。因此，我对这个项目的要求是：

• 不引用其它代码库，也就是说手写包括USB协议栈和CMSIS-DAP源码内的所有代码

• 对于JTAG和SWD，使用SPI进行加速，SRAM的读写速度突破300KB/s

• 必要时编写汇编来处理关键代码，包括IO操作和ISR等

• 保留后续添加新功能的能力，在Flash足够的情况下可以根据需求进行扩展

• 丰俭由人，BOM的成本可以压到2块钱甚至更低，也可以添加电平转换芯片等外围电路构成更完整的调试器

对于一个项目，我们当然要定个目标，我觉得目标可以分成基本目标和进阶目标，基本目标是做一个可以和DAPLink的基础功能大致对齐的调试器，进阶目标则允许和其它基于DAPLink的调试器构成差异化竞争。

基本目标：

• CMSIS-DAP协议支持，包括v1（基于HID）和v2（基于WinUSB），不需要切换工作模式

• SWO支持，波特率可以达到3Mbaud

• 异步串口支持，波特率可以达到3Mbaud

进阶目标（构思中）：

• 加入OLED显示屏和按钮，实时显示信息并允许简单操作

• WCH RISC-V调试协议支持（视协议开发情况而定，目前只有单线协议开放）

• 基于CMSIS-DAP的Vendor Commands实现新功能（强制调试时钟频率等）

由于是从底层搭起，想必会花费不少时间把这颗单片机摸透，不过至少SWD和JTAG的前置知识已经都在前文覆盖了，关于CMSIS-DAP协议的支持应该也会在后续提到。本贴应该会在接下来的几个月中缓慢更新，敬请期待。

ch32x033还可以利用PIOC加速，可能比SPI加速更合适，难点和创新点在PIOC的代码。隔壁网站ch32x035开发板试用俺以做个daplink并PIOC加速为试用出发点申领试用，然后被据.。。。然后我看了那些申请通过的试用方案，一言难尽>。

不过也好，先忙其它的，准备哪天等手里项目做差不多再到wch那买一块开发板来做软件方案。

@xkrisc
PIOC引脚太少，搞不定JTAG，还是走SPI吧，虽然还需要加点IO模拟，不过速度应该够用了。

这点我同意，现在的DAP调试器市场主要是两种方向，一种就是像你说的，只是简单地把USB协议栈和CMSIS-DAP或者DAPLink代码拼接起来，看着还行，实际体验并不好，总有各种小问题；另一种就是使用高端芯片做更好的功能，但是价格相对来说也比较高。
我想做的可能会更“极端”一些，对于低成本的方案，还是使用廉价MCU，但是通过重写相关的代码，实现更高的性能，解决一些潜在的问题，让低价调试器不低质；高端方案我比较想尝试基于FPGA的方案，做到更好的传输质量和更低的延迟。当然，这些只是设想，不过我也不靠这个盈利，所以会花时间来慢慢打磨，满意了再发布。

我觉得MCU+FPGA方案性能虽好，但复杂度太高了，容易影响稳定性。性能和稳定性应该是调试器在使用体验上最重要的指标。
我觉得这两种方案比较容易实现性能和稳定性：带FPGA的MCU、先楫半导体的 HPM5331

但带FPGA又带USB HS PHY的MCU似乎没有。

HPM5331的SEI接口可以适配任意时序的串行通信协议，并且有两个SEI及USB HS PHY

最近编辑记录 海石生风 (2024-05-31 17:03:25)