WhyCan Forum(哇酷开发者社区)

之前用CMSIS-DAP测试过，速度感觉不太理想，目前在尝试其它方案，等搞定了应该会开源的。晒下目前的硬件设计，软件部分还没开始适配：
至于驱动CMSIS-DAP，俺是直接用pyUSB发送和接收数据的，用的是CMSIS-DAP的DAP_JTAG_Sequence命令，用法还是比较简单的，可以参考官方文档：CMSIS-DAP: DAP_JTAG_Sequence

尝试测了一下CoreMark，分数还不错，基本上和STM32F407在一个等级，248MHz（数据手册中最高频率）能到630，384MHz（最高可运行频率）到了976以上，不知道这个分数是否意味着AG32VF407/AGRV2K的Flash有cache或者零等待执行。

CoreMark的工程可以在这里下载：CoreMark.zip，可以通过修改coremark.ve文件中的SYSCLK来调整时钟频率。

@echo
主要原因是我手上的AtoC线比其它线都多，插座也是😂当然USB-C也有优势，比如说电源触点多能过大电流（USB-C插座基本上都能过3A），对只有USB-C的笔记本更友好（CtoMicro的线基本上只能另外买），线材质量相对更好（毕竟成本本来就更高）等，正反插毕竟也还是更方便的。

在更新到Supra之后，看起来支持CMSIS-DAP了，这样一来可以搓一个带下崽器的最小系统，好评。

如果对AGRV2K的工作原理感兴趣，可以打开AgRV_pio\platforms\AgRV\builder\main.py文件，里面详细记录了各个工具的使用方式。

某天在逛淘宝时，发现AGM店里上了个有趣的芯片：AGRV2K100（CPLD） AGM FPGA CPLD替代Altera EP1270 内嵌MCU，遂买来玩玩。接下来就发生了意想不到的一些事情：

1. 我在早上下了一单，结果晚上到家的时候就发现快递躺着家门口了，这也太效率了。后面了解到他们一天会发两次货，并且刚好有本地仓库，所以当天就收到了，而板子都还没准备好。

2. 收到货的时候，发现并没有收到想要的AGRV2K，反而收到了AG32VF407。后来才知道，原来AGRV32和AG32VF407是同一颗芯片，估计厂家没有重新打标，直接就推了。

3. 发现卖家“发错”之后立刻联系卖家，结果卖家在晚上直接就打电话过来了，详细解释了丝印的问题。后面我也确认过，这两个确实是同款芯片。

来点当时刚刚收到的芯片：

是的，先从简单的做起，熟悉下上位机。
不过这个会按照自己的想法做一些功能，具体的话可以期待一下🤭

目前没有适配商业软件的计划，不过到时候应该会开源全部代码，可以自行适配。

其实sigrok可能未必是最好的，原因上面有总结过，主要是USB分析仪需要能分层次呈现相关信息。至于其它方案，我想到的比较好的有两种：

1. 使用已有的开源USB分析上位机，比如上面提到的ViewSB（不过这玩意实在是太半成品了一些），或者是同一个作者正在优化的Packetry。这个比较适合实时捕获，不过功能上还比较简陋，需要优化。

2. 将数据保存为其它工具可以打开的形式，之后可以进行离线分析。这个我能想到最好的软件是Wireshark，配合相应插件可以实现USB Class级的分析，并且有强大的功能支持（例如正则表达式筛选）。按理来说这个工作量不会很大，不过似乎没有看到过成品。

@bigniudiy

我手头也有LUNA，是之前淘宝那个众筹的版本，从FPGA到上位机都跑过了，ViewSB可以正常抓包，Windows和Linux都能用。这方面有问题可以交流下。
另外，LUNA那个协议栈我也尝试过移植到其它FPGA板子，Sipeed Tang Primer 20K的USB demo就是俺搞的🤣不过导出Verilog这事儿做起来太麻烦，最好还是能用Lattice这样有全套EDA工具的FPGA来玩。

这个挺适合做高配版本的，加上CH569可以实现功能完整的USB分析仪了，BOM成本可以做到80-100。
不过呢，这次我打算从低配版本做起，先验证下功能再确定高配版本的设计。
这一版计划使用更低端的MCU和FPGA，成本减半应该没啥问题，主要看功能是否满足需要。估计月底可以画好板子，之后看软硬件要调试到什么时候了。

@Blueskull

LUNA确实底子挺不错的，这也是主要参考它的原因（这个项目没有参与过哈哈，顶多就是产品的使用者而已）。可惜HDL部分更新缓慢，现在HyperRAM都还没用上，等到USB分析以外的功能都做好估计得等到众筹发货了（是的，前年的众筹发货时间已经推迟到今年年中了），不过倒是已经有不少人已经有板子了（毕竟硬件都全开源了）。
我也有一块LUNA的板子，价格不贵（接近200），作为FPGA感觉性价比尚可。不过如果只是想做个USB分析仪的话，感觉还是有些浪费，所以在考虑做一个低成本方案，只做一件事情的话应该可以把FPGA砍成低容量的型号。

先说结论：这样做没有语法错误，但很可能达不到楼主想要的效果，除非明确自己需要做什么，否则不建议这么写。
具体代码的编译结果可以参考这个：https://godbolt.org/z/57EfcK7eM（为了避免编译器的优化，对case值进行了少许修改）。

接下来说说C语言里面switch和case的逻辑，可以参考C语言的规范，例如C99：https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf。
可以看到，C里面的switch的功能实际上很简单，说起来就是：

1. 首先计算switch内的表达式的值，C要求计算的结果必须为整数（即integer）。

2. 接下来会找到值匹配的case，如果没有匹配的值则会跳转到default（如果有），如果没有则直接跳出整个switch。由于C语言限制了case值不能重复，也不能有多个default标签，所以从switch到case/default的跳转是唯一的。

3. 跳转到相应位置后，依次执行代码，直到遇到break提前终止或者完成整个switch。

至于case，其实case可以理解成是一种带常数表达式的label（也就是goto跳转到的地方），因此case可以出现在switch内的任何位置，但这个位置是直接跳转过去的，并不会去执行前面的语句。以楼主给的代码为例，这里if(y==1)实际上就是永远不会执行到的代码，因为上一个case结束时有break，而下一个case是在if语句里面，从执行的结果上看相当于没有这一行代码。现在，对比上面给的编译结果，应该就很容易理解为啥完全没有出现r1（第二个参数）这个寄存器了。

最后贴一个C99规范里面的例子，以及相应的说明：

有没有一种可能，里面不是ARM的核心呢🤣

顺带一提，双层沉板USB Type-A用的是这个：U224-081N-1WRZ21-S-1_（XKB Connectivity(中国星坤)）U224-081N-1WRZ21-S-1中文资料_价格_PDF手册-立创电子商城，焊好后板子的厚度在1.5cm左右😎
另外，为了控制阻抗，这个板子用了4层铜，在嘉立创打样的话需要选择7628叠层。

334U和官方确认应该没问题，334R在等他们月底的样片。

CH340X的封装太小，只有TNOW而且还跟DTR复用了，这个实在办不到😂

BL808定位和V831比较类似（CPU性能差点，编码器不支持H.265，优势是自带无线），所以感觉价格上不太可能太低，盲猜20块钱吧。
不过，博流还有BL616/618还没亮相，这个性价比应该会更高，可以等一等。

尝试去猎板网打了一版猛男粉，颜色比想象中淡一些，感觉还不错。

好消息，板子在Muse Lab上架啦~链接是https://item.taobao.com/item.htm?id=686942510375，辛苦晕哥帮忙改下标题和顶楼😘

现在推荐玩玩CH32V203G6，性能全方位优于CH552T，封装也更小（QFN28，4x4），价格的话批量也可以做到2块以内。可以参考这个帖子：CH32V203G6最小系统板正式开源，可能是最小的RISC-V全引脚开发板。

直接连上的话，相关引脚就没法用了，毕竟沁恒有个把PA10和PA11直接连到同一个引脚的天才设计😂

看这张图就秒懂了😏
这里有个有意思的地方，由于PCB内芯稍微有些发黄，正面看是粉红和冰蓝的LED，到了背面就变成橙色和绿色，实测效果还不错。

嘿嘿嘿🥵🥵🥵

@echo

另外，即使都是高速USB，相互之间也是有比较明显的性能差距的，这个可能和具体的实现有关，我这里不是很了解，这里有一些相关数据：https://blog.csdn.net/rui22/article/details/107814146 。DLC9和Digilent的方案的对比应该是比较多的。
（当然，最典型的反面例子就是只用CY7C68013A不用CPLD的方案，这种方案的IO速度受到CPU的限制，实际上确实不如新的USB全速方案，但是用GPIF或者Slave FIFO的方案理论上来说要好一些。）
说到底，我觉得最大的问题是高速USB对于纯下载用途而言确实应用面比较窄（原因如你所说，大容量芯片本身就是偏专业向的用途，和开源社区目前关注的方向不是很合拍），而可以发挥其优势的用途（如大容量FPGA下载，片上逻辑分析仪等）又容易受到上位机的制约（通常只支持特定型号的下载器，对开源方案不友好），估计需要多做一些工作才能达到期望的效果。

问题的关键是全速USB是否会成为FPGA下载的瓶颈。对于高云这种限制了JTAG烧录速度的FPGA来说确实用处不大（因为JTAG时钟频率上限低于12Mbps的一半），但是如果FPGA支持更高的时钟频率的话，还是有帮助的。
有个人给过我一个数据，说是CH32V307下载7K325T能到3MB/s以上的速度，这个速度显然就超过全速USB的上限了。不过这个数据我还没验证过，不知道实际上能否达到（对应的JTAG时钟频率得超过24MHz了）。

最近可以试试CH32V305那个开源的调试器固件，看看有没有问题

建议参考USB-C的相关标准，里面有详细记录各种转接线和转接头的连接方式，按照这个来准没错。USB Type-C Specification Release 1.3.pdf

收到芯片了，KEU7的封装确实小，必须给好评。
话说ACM32F403的datasheet和用户手册晕哥可以发一下吗，官网好像GG了😂

从指令集来看，Cortex-M4支持Cortex-M3的所有指令（虽然M4可能会在部分M3支持的指令上有性能优化），因此理论上来说是可以兼容的。
另外，Cortex-M3的主频完全可以做得很高，只要堆制程就行。可以了解一下RKNanoD，双核Cortex-M3中有一个核可以跑到400MHz。

协议层

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

周末又尝试优化了一波速度，在MCU-LINK搭配CMSIS-DAP V2，时钟频率为14MHz的时候，跑出了还不错的结果：
不过在尝试继续提高频率时无法识别到FPGA了，现在还不清楚是否和固件有关系。

前排抱走小正太🤤

这个就是之前Intel大名鼎鼎的两个漏洞，Spectre和Meltdown，当时的修复补丁确实会显著降低性能。不过看帖子的话似乎没有讨论出为啥对其它虚拟机软件影响不大。

@zhangqasd

是的，FT_PROG不会改这个区域，但是Vivado会使用上面的数据进行验证，包括Digilent的调试器也是一样的。
FTDI的驱动中有提供EEPROM烧录相关的API，可以直接调用，当然用ftdi-eeprom也是可行的。

日式轻小说标题了属于是🤣
另外这个板载的zero确实是比较早的版本，可以对比板子屁股后面的logo（从sunxi到sipeed lichee zero

后面抓了一下波形，感觉是类cJTAG的协议，逻辑分析仪选cJTAG似乎可以解析出正确的数据，不过J-Link选cJTAG不能正常识别。

@Blueskull

FT602应该是支持UVC的，可以直接接摄像头。不过FTDI家这个系列的芯片确实主要是桥接用的，需要开发更复杂的工作模式还是只能考虑CYUSB3014、CH569这种。

666，期待开源

沁恒还有CH565/569和CH32V103

试过改成两个JTAG的配置，确实可以有两个JTAG，但是Vivado只能识别出其中一个，这个应该是软件的限制。
如果对这方面感兴趣，可以看看libftdi的源代码，里面有你想要的答案。

看到楼主的另一个回复了。有篇论文给出了几个IC的型号和一个稍作修改后的原理图，但没有直接给出SMT3-NC的原理图，可以参考一下。An Example of PCB Reverse Engineering – Reconstruction of Digilent JTAG SMT3 Sche.pdf

我都花钱买板子了，还要花时间玩，不是太过分了吗？（手动狗头

好东西，之前买了片子，现在可以蹭免费打板了。

这个帖子是我开的，当时二楼的回复是兼容ARM的SWD，后面他们自己删了😅

现在能买到的貌似只有RV-Debugger Plus，不过这个其实是个调试器，意味着要当开发板用还是有点别扭。
如果想玩芯片的话。。建议直接问问@泽畔无材 老板。

整理一下目前找到的资料：

• Sipeed提供的资料（包括原理图、BSP和已经开发好的固件）：sipeed/RV-Debugger-BL702

• Bouffalo的GitLab：Bouffalo Lab

• Bouffalo的Gitee：博流智能科技（南京）有限公司

• 官方文档：BL MCU SDK 开发指南

• 开发者社区（包括文档、论坛等）：博流智能开发者社区

• SiFive E24的相关文档：

  • sifive_E24_rtl_full_20G1.03.00_manual.pdf

  • SiFive VIC_E24 User Guide.pdf

  • SiFive VIC_E24 Manual.pdf

PIO部分用的是汇编代码，也只能写汇编。

是啊，又找到了一个拖更的理由（不是

@Blueskull

Quartus默认不支持FTDI的芯片，不过我在网上看到一个号称可以通过替换dll支持的方法，链接如下：https://mil.ufl.edu/3701/docs/quartus/quartus18.1_installation.pdf。
手头没有Altera的FPGA板子（严格来说有但是板载了下载器233）所以没法测试，可以试一下好不好用。

默认15M，最高30M，和其它FTx232H芯片一样。

这个不错，如果能支持PPS之类的就更好了，可以当一个小型直流电源用。

乐鑫官方店买的ESP32-C3FH4到了，搭了个简单的电路，可以识别到USB JTAG和虚拟串口，好评。
需要说明的是，USB能不能用和硬件版本（WAFER_VERSION）有关，只有版本为3或以上（貌似暂时还没有）才能用USB功能。可以确认的是，安信可之前的3.9开发板和低价模块都是基于版本2（但据说现在正常价格的模块和开发板已经是版本3了），而官方店里卖的都是版本3。

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

安信可发货了，不过开发板的资料还没有，客服说之后会在官网更新。

STC8H8K64U应该还在样片阶段吧，而且价格似乎并不算便宜。如果USB端点数量够用的话可以试试CH551/552（EP1-EP4），价格更便宜。

这个是8080的哦，SPI代码可以参考中景园电子提供的，他们的淘宝商品页面有相关资料的网盘链接。

在楼主这买过芯片，支持一下，祝以后的人生更精彩。

和eFUSE里面的CFG_AES_ONLY这个位有关，默认在加密后是可以用未加密bitstream的，这个位被编程之后就不行了。

不是的，GD32VF103（注意不是GD32F103）是RISC-V的CPU，不支持SWD，只支持四线的JTAG协议，所以要调试的话需要从两个地方都接出来，不是很方便。
至于CH32V103，沁恒实现了和SWD相似的RVSWD（只是引脚相同，协议应该不兼容），所以倒是不像GD32VF103那样有这个问题。不过看起来CH32V103在协议没公开之前只能用他家的调试器了。
话说GD32VF103的接口定义可以参考Sipeed Longan RV，两面共引出2x4p的2.54mm接口，不过接口稳定性堪忧，我的那块板子就被我把焊盘弄掉了

感觉应该也兼容CH32V103？另外GD32VF103的调试口是JTAG，好像不是很方便，可以考虑引出JTAG的所有接口。

没作用是什么意思，没有写到Flash里面？
感觉可以USB抓包分析一下。

我记得坑网有个人有CH552的V2版本。
至于俺之前说好要写的那个，最近发现源代码被俺搞丢了，估计需要花时间重写了，嘤嘤嘤

搜了一下，能看到的最早专利似乎是这个：Communication Interface for Diagnostic Circuits of An Integrated Circuit，2023年8月到期，不过不清楚是否还存在后面改进的版本。
在中国的专利号是CN100487472C。

这两天正在看RP2040的datasheet，我觉得SIO（主要是里面的Interpolator）和PIO是非常有趣的两个东西，值得研究。如果不太忙的话争取整理点文档出来。

一方面，RP2040有SRAM，而且AHB-Lite总线的Crossbar映射是完整的，意味着两个核的访问可以做到互不冲突，可以把关键代码放到SRAM以提升效率；另外，RP2040对于Flash有16KB的Cache，这个Cache应对（简单的）NES游戏来说应该是比较够用的。

如果“调用了很多次”的意思是在调试窗口中多次经过同一行代码，那这个是正常的，因为一条代码可能被拆成多条指令，而编译器在优化的时候会在不改变代码逻辑的前提下重排序这些指令，导致调试的时候会依次执行代码对应的多条指令，反映到调试窗口就是这个现象了。

感谢分享，有时间打板试试

我知道有厂家会用继电器来做启动时的噪声屏蔽和静音，不过这个成本比较高。

两周前就拍了套件，今天终于有时间用起来了，焊好上电一次通过，好评。

新版本的U-Boot已经自带了STM32F429，不知道能不能用

K210是那个483页的文档？

之前看过一个更骚的操作（仅对于FPGA有效），可以给每个引脚安排一个输出当前引脚编号的UART发送单元，之后只需要用一个串口模块就能读取每个信号的对应引脚编号了。

当前Windows 10对UAC 2的支持已经比较完善了，应该可以玩玩。楼主可以先把数字部分做好再来搞模拟部分。

HDMI有个EDID信息，存储在EEPROM中，可以通过I2C协议读取显示信息，应该有相关的软件可以做这件事。

太强了，支持一下

200

之前在外网上看到SMT2的示意图，不过没试过，不知道是否可用。

可以，个人更喜欢第一版。

可以试试WSL（Windows Subsystem on Linux），可以在Windows下直接运行Ubuntu，同时还能调用Windows程序，运行速度比虚拟机快。

iCEcube2和Radiant生成的bitstream都可以直接烧录到SPI Flash。
另外，iCEcube2和icestorm使用的原语应该是兼容的，Radiant用了新的原语，需要迁移才能使用，除此之外应该没有很大区别。

一直在等他关于F1C200s解码的文章，哈哈。

楼主对HI3518EV300有兴趣吗？自带人脸检测和异常声音检测，感觉有点意思。

linux/Kconfig at master · torvalds/linux