WhyCan Forum(哇酷开发者社区)

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

RISC-V的调试速度测试

测试方法：比较各个调试器单步执行（step over）的执行速度

测试工具：SEGGER Embedded Studio for RISC-V（集成开发环境） + Sipeed GD32VF103最小系统板

测试对象：以下各种调试器/工具的组合。

• J-Link V10 EDU（正版，目前V10明确支持RISC-V，其它版本未知），可选直接连接、GDB Server和OpenOCD

• FT232H开发板（应该可以代表FTDI支持USB HS芯片的性能，包括FT2232H/FT4232H），仅OpenOCD

• LPC-Link2，刷了CMSIS-DAP固件（包括LPCScrypt提供的版本和CMSIS-DAP自带版本），仅OpenOCD

• 淘宝常见的STM32F103C8T6最小系统板，刷了CMSIS-DAP固件，仅OpenOCD

测试结果：
J-Link (直连) > J-Link (GDB Server) > J-Link (OpenOCD) ≈ FT232H >> STM32F103C8T6 with CMSIS-DAP
由于OpenOCD不支持非基于HID的CMSIS-DAP（针对USB HS可使用Bulk传输，速度更快），LPC-Link2退出了群聊。

结论：
1. J-Link对RISC-V的支持挺不错的，调试速度和其它平台没啥区别，现在唯一遇到的问题是不支持显示自定义CSR，对于调试基于Bumblebee内核的GD32VF103（特别是ECLIC相关的部分）而言颇为不便。
2. OpenOCD对调试器的支持面很广（除了使用Bulk传输的CMSIS-DAP，但这个比较小众），不过调试速度一般，显然存在瓶颈。目前看来OpenOCD可以支持自定义CSR，但还需要IDE的支持才能方便地显示。
3. CMSIS-DAP的调试速度简直是弟中弟，大于5秒/指令（注意不是代码是指令）的速度基本无法忍受。

注：STM32F103C8T6的CMSIS-DAP固件见RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO，调试Cortex-M单片机的时候速度比较正常，应该不是固件本身的问题。

最近编辑记录 metro (2019-09-17 11:21:31)

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

请教，ft232不是usb转ttl芯片吗？这个如何实现openOCD?

这个是FT232H，支持MPSSE，可以配置为JTAG协议。FT232H/FT2232H/FT4232H都支持这种模式。

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

为了探究各个调试器调试/下载速度差异的根源，这里尝试使用逻辑分析仪抓取JTAG波形的方式进行分析。
此处的比较对象包括J-Link（直连）、J-Link（OpenOCD）、CMSIS-DAP（OpenOCD）。JTAG时钟速度为1 MHz，不过直连时的速度似乎是4 MHz，这个对分析没有影响。

J-Link（直连）：

J-Link（OpenOCD）：

CMSIS-DAP（OpenOCD）：

可以发现：
1. 单步执行的速度大致为J-Link直连 (5 ms) < J-Link+OpenOCD (450 ms) < CMSIS-DAP+OpenOCD (3050 ms)，可以发现速度之间的差异是巨大的。
2. 对比J-Link+OpenOCD和CMSIS-DAP+OpenOCD，这两种方案传输的数据量是差不多的，主要区别在于指令之间的间隔长度。
3. 造成J-Link直连和通过OpenOCD这两种情况速度差异的因素，主要是OpenOCD的处理序列较长，这个问题我们在后文分析。另外还有一个原因是OpenOCD不支持将调试指令队列化处理，使得每次USB传输时只能访问一个寄存器，调试器在大部分时间是空闲状态，效率很低且调整JTAG时钟无法改善。
4. 由于2中提到的调试指令处理速度，所有使用OpenOCD的方案的瓶颈都在于USB传输频率。我们知道，USB 2.0 HS的最大传输频率为8 kHz（每秒可以传输8000个subframe），而CMSIS-DAP通常是HID设备（官方OpenOCD只支持这种方案），而HID的传输频率实际上与报文的interval相关，这就造成了至少8倍的时间差异。不巧的是，在时间增加数倍之后，调试速度已经影响到了正常执行，变得无法忍受。
5. 此处还测试了J-Link+GDB Server方案，发现JTAG波形与直连时没有太大区别，猜测主要的差异在于GDB Server引入的延迟。

因此，在OpenOCD没有大的改进之前，建议尽可能使用USB 2.0 HS接口的调试器（FTDI的高速IC方案不错，FT232H/FT2232H都可以），或是直接使用J-Link等自带调试软件的方案。

最近编辑记录 metro (2019-09-24 17:02:04)

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

我抓了一组使用OpenOCD的JTAG波形，并且进行了适当解码。大家可以看看OpenOCD的调试指令有何问题。CMSIS-DAP.zip

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

问题太高深，不懂哦， 就像问下 J-Link V10 EDU 活动的时候什么价格？

呃，我是在Mouser上以原价买的，似乎当时比某宝上便宜，但是现在已经买不了了。。

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

这里简要分析一下OpenOCD的操作指令。

上图是未解码前的原始JTAG数据。可以发现，每次访问寄存器时JTAG分别都需要三次操作，分别是写IR（切换DTM寄存器）、写DR（发起传输）、读或写DR（验证传输正确性，读操作时同时获取结果）这三部分。在绝大部分情况下，我们只需要访问dtmcs寄存器，因此写IR这步通常是多余的；另外，在连续读取数据等情况下，没有必要每次专门发起一次传输来验证传输的正确性，而是可以先发起下次传输，视返回值确定上次传输是否成功。这里可以节省2/3的传输。

上图是简单解码后的传输内容。通过研究可以发现，在每次单步调试时，OpenOCD都需要完成暂存寄存器、写入算法（通常是单步调试）、执行、还原寄存器等操作。暂且不提这些操作的必要性（显然可以通过记录数据是否已改变的方式减小需经过调试器访问的数据量），上图中还可以看到这里执行了许多明显错误的指令（可以看到Debug Module报错了）——更可怕的是，这段代码足足重复了34次（仅CSR地址略有不同）。不是很清楚为何OpenOCD会做这些事情，可能需要研究一下OpenOCD的代码了。

最近编辑记录 metro (2019-09-24 18:36:23)

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

关注

请问CMSIS DAP下载速度怎么样？

我买了20片 GD32VF正准备贴，手上只有DAP LINK。

不过我通常不用调试，只是用来下载程序，大部分调试都是用串口输出LOG。

我自己的测试结果是J-Link < FT232H < USB DFU << CMSIS-DAP (Full Speed)，完全写入（128 KB）的话J-Link在5秒左右，FT232H和USB DFU的话大概十几秒，CMSIS-DAP需要五六十秒。

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

这种FT2232能用吗，或者有推荐的某宝链接没？
https://whycan.cn/files/members/390/O1CN018IJai42GL8Hi3xAV0_3301708998.jpeg

应该可以，我用的就是同一家的FT232H

metro

会员

注册时间： 2019-03-09

已发帖子： 445

积分： 489

Re: RISC-V的调试速度测试

我编译了两个支持cmsis-dap v2的openocd执行文件：https://github.com/vllogic/openocd_cmsis-dap_v2/releases

cmsis-dap v2对于ARM芯片效果很好，对于riscv或者esp32效果不佳，不过这个锅应该扣给openocd

感谢分享！
根据之前的经验，OpenOCD的速度不行，一方面是没有利用好CMSIS-DAP的Atomic Commands（一次性处理多条指令），配合USB 2.0 FS的传输频率（最高1 kHz），一次只能处理一次寄存器读写，速度自然十分感人；另一方面则是无效操作过多，有一些错误或者多余的指令，使得传输效率远低于J-Link。当然这也和CMSIS-DAP本身就是适配ARM处理器有关，不过感觉还有很大的优化空间。