让 CMSIS

折腾了一段时间，总算有所成果，随写随贴... 抛砖引玉，先分析当前能够见到的DAPLink的问题。

1.当前DAPLink产品存在的问题

1.1 烧写速度如果有细心的人尝试比较过市面上的DAPLink和STLinkV2，那么可以发现DAPLink的烧写速度要慢于STLinkV2。

如果目标芯片的FLASH比较小，例如网红芯片STM32F103C8T6，只有64KB，那么对比烧写速度是不明显的，但是要烧写FLASH大小为512KB，甚至1M的MCU时，速度差距就非常明显。

这并不意味着DAPLink做不到更高的速度，或者硬件方案不能满足，实际上当前的DAPLink硬件解决方案和STLinkv2的硬件解决方案通常都是基于XX32F103C8/BT6实现的。由于近段时间原厂STM32芯片的价格大幅上升，目前基于原厂STM32的方案很少(或者用拆机回收芯片)，大部分进行了国产替代。但是无论哪种硬件，速度上是完全可以满足SWD协议需求的，后面会分析为什么。

在metro的大作中将CMSIS-DAP移植到了增强型C51单片机CH558 上，并实现了下载到目标芯片STM32F407的速度70KB/s。这个速度实际上已经可以比肩STLinkV3(注意，不是V2)的速度了。也就是说72M主频的STM32方案是完全可以做到更高速度的。

这里简单分析下制约当前市面上DAPLink下载器下载速度的瓶颈，主要归结为两种：

原因1：HID协议大部分产品都是基于CMSIS-DAP HID协议的。CMSIS-DAP提供了两种USB通信协议版本，早期的HID协议版本(DAPLink v1)和最新的Bulk版本(DAPLink v2)。HID和Bulk均是USB协议中的通信实现方式。HID是针对人机交互设备的，例如平时使用的鼠标，键盘，游戏手柄等，这类设备通信数据量很小，但是要保证最小时延。由于USB2.0协议通信是需要主机发起的，也即设备不能主动通告，HID规定最小时间间隔为1ms，PC会轮询一次设备来读取信息。 USB2.0最大支持的包长为64字节，这就意味着HID最理想的通信速率是64/1ms = 64KBps，这看起来还不错。但是CMSIS-DAP协议是Ping-pong模式的，也即需要发一个命令请求，然后等待响应，然后继续发下一个命令，这样就导致，即便在理想情况下发送64字节至少需要2ms，直接速率打对折，极限速度只能到32KBps。

原因2：SWD/JTAG实际频率远远未达到10MHz通过Keil等上位机可以设定DAPLink调试协议的工作频率，通常默认就是最高频率10MHz，这比STLinkV2的工作频率要高一倍(STLinkv2的SWD频率官方宣称为4MHz，实测大约在4.3MHz)。

而市面上的大部分DAPLink虽然设置了10MHz，然而实际测试发现，工作频率只有600-700KHz。这相当于实际工作频率只有标称频率的10分之一都不到。

SWD实际工作频率测试方法很简单，调试器连接目标芯片，Keil下载程序然后进入调试模式，此时只要将SWCLK接示波器探头，GND接示波器探头地，然后选择下降沿触发即可看到波形，测试某产品在选择10MHz时的实际工作频率：

令人感到意外的是，笔者使用过3种不同硬件，不同包装方式（亚克力外壳版本，仿STLinkV2铝壳版以及TypeC接口的裸板版本），每一种使用的芯片都不同，另外这些产品的序列号是不同的，也即基本可以确定不是使用的同一固件，但是却得到了相同的工作频率，这就可以猜测，这些厂商都是直接拿ARM开源社区的源码进行了简单移植，也即直接编译的。并没有针对特定的硬件平台进行时序的调整。

所以这类固件即便将USB协议切换为Bulk也是无法提高烧写速度的。

1.2    CDC虚拟串口卡死基于USB协议的虚拟串口通常有2种实现方式：VCP和CDC，最主要的区别就是VCP是需要安装厂商定制驱动的，例如基于CP2102芯片方案的USB转TTL小板就是VCP方案。由于厂商的驱动针对自身硬件方案进行了特殊优化，通常情况下VCP的性能更好。

CDC是USB协议提供的通用串口虚拟方案，各类操作系统自带驱动, 无需再安装驱动，使用方便，但是性能通常没有VCP的好。但是对于只用于打印调试信息的调试器来说，CDC方案已满足这种需求，并且提供了即插即用的便利性。

但是目前测试发现，所有被测的三款产品都会出现CDC卡死问题，特别是在下载和调试时，如果同时使用虚拟串口打印，那么很容易出现卡死现象，并且只能重新插拔才能继续使用。目前看是DAPLink基于STM32F103的开源方案在处理UART接收上有问题，否则不可能所有的厂商都犯相同错误。

手头有类似调试器的朋友可以使用串口测试工具，例如UartAssist.exe来测试下串口吞吐量，直接将RX/TX短接，然后关闭数据回显，间隔时间调整到最低，每次发送64-256字节的数据包，基本上几分钟就会卡死。从现象看应该是典型的Cortex-M方案的UART ORE上溢错误。这类错误一旦出现如果不清0相应寄存器，则UART硬件模块就不再接收新数据，现象为串口卡死。

1.3    不支持软复位软复位是SWD协议特有的针对Cortex-M芯片实现的无需RST硬件连线就可以实现复位的功能。

DAPLink调试器在收到上位机的软件复位命令时，会在RST管脚生成一个复位脉冲（低电平），与此同时在SWDIO数据口发出一段复位序列，Cortex-M芯片中的DAP调试模块收到该序列后就会复位芯片，起到和连接RST相同的作用。

可惜的是这些调试器都没有适配该功能，查看了ARM开源社区的源码后，发现也没有实现该功能，这就解释了为何大部分厂商没有（似乎也不知道如何）适配该功能。

1.4    不支持JTAG之所以不支持JTAG，理由似乎也和不支持软复位一样，原开源代码中只实现了JTAG协议，但是没有实现USB数据到JTAG数据的对接。

JTAG协议是相比于SWD更通用的调试协议，对于具有DIY精神的朋友，如果了解了JTAG协议和OpenOCD或者pyOCD，那么通过DAPLink的JTAG协议就可以做出烧写其他芯片的方案，当然实现调试要困难一些。

此外通过JTAG协议还可以实现边界扫描，对于了解目标MCU的芯片设计有很大帮助。有国外网友通过JTAG破解XXX，有兴趣的可以了解下。

SWD提供了普通用户的调试和烧写需求，而JTAG则为更富DIY精神的Geek们提供了了解MCU内部硬件结构的大门

1.5    其他小问题遇到有一家的DAPLink的所有产品都是使用的开源代码中写死的A0000xxx序列号，也就是说你一台PC只能插入一个调试器，如果需要同时调试多块板子，或者一块板子上有多个MCU需要同时调试，那么只能换一台PC，因为上位机只能识别出一个调试器。对于这种低级错误只能无语了。

有些产品没有提供5V供电接口。

有些只是使用串接小电阻的方式兼容3.3V和5V，实际上这很容易引起电流倒灌，导致调试器工作不稳定，长时间使用引起元器件失效。

大部分产品提供了自恢复保险丝，可以在5V短路时有效保护电脑USB主板。但是如果3.3V供电口不小心碰到地，或者触碰到5V端子上，LDO可能直接损坏，固件丢失，或者电压输出不在正常范围之内，导致调试器工作异常。（这里提醒手头有这类调试器的网友不要做此类实验，山寨的STLinkV2也不要做，否则很可能瞬间损坏，笔者进行过故意接错实验，发现丢固件现象，几乎必现，毕竟STM32芯片不支持5V供电，所以“易耗品”的名头很可能是此原因导致的）。

2 现有产品亮点目前看能在官方DAPLink上能有所创新，功能有所增强的很少，大部分的做法都是（有意或者无意）在软件功能和硬件上做减法。对于普通的消费者这是好事，但是能够购买到更快更稳定的产品也是终端用户的需求。

但是这并不意味着所有厂商都只奔money，而是有所创新，无论是在外观上还是功能上。MuseLab家做的DAPLink是可以支持JTAG和软复位的，必须点赞。

有的厂家适配了TypeC接口，这样更小巧精悍。实际上笔者并不认同必须使用TypeC（micro USB口也一样，对于DIY来说更易焊接），因为根本就使用不到USB3.0，但是它的意义在于可以将USB通信端延长，而缩短调试线的长度，这样SWD/JTAG通信距离变短，更加稳定。此外不得不承认TypeC接口更美观。

使用USB A口（STLinkV2的USB口）的调试器，如果用在台式机上，那么由于A口只能直接插在主机上，那么调试线就要很长，否则开发板必须放在主机旁边，很不方便。这一点深有体会。或者使用A口的延长线，但是没有TypeC和micro USB口的延长线常见，基本上买手机或者其他电子产品都会附送这类USB传输线。

相比于STLinkV2的单一铝壳封装，可以找到各种封装的DAPLink，为喜欢DIY的人提供灵感。笔者最开始看到的是透明亚克力外壳，看起来比较精致，这种外壳原本是用于一些USB电流电压表，后来被用于改造DAPLink。缺点也很明显，容易刮花，个头大，实际上高度可以压缩一半，体积也可以做得更精致，但是需要定制，量不大的话无疑增加成本。另外A口调试接延长线不是很方便。

DAPLink同样也有类似STLinkV2的铝壳封装，这种封装比较小巧，但是只开一个孔，电源灯和信号灯都是通过该孔观察，算个小缺陷。不知道为何当初STLinkV2的山寨厂商不多打一个孔？而且固执得坚持这种外壳形式很多年，变得只是上面的丝印和LOGO（说一个有趣的事情，曾在某宝评论区看到某用户发此评论：本来是要买ST原厂的，发的竟然不带ST的Logo。所以也可以看到ST公司对山寨厂商们的容忍程度，竟然让终端用户以为打了ST的Logo的STLinkV2就是原厂的，不过固件确实都是原厂的）。另外，同样地A口接延长线不方便。（也正因为有铝壳，STLinkV2版本各类“奇异”芯片神出鬼没，只要能兼容原厂固件即可。）

裸奔，这种类似开发板发售的形式成本最低，硬件底板形状随意，功能扩展容易，不会受到底板大小的限制，所以为何只做呆板无趣的长方形？完全可以充分发挥想象力，做个卡通形象，例如紫色佩奇，增加亮点吸引小小开发者:-）。正因裸奔，不用考虑外壳的限制，可以衍生出TypeC版本。缺点也很明显，裸奔就意味着有被咸猪手触碰的风险，使用的时候很容易触碰到裸露的金属点，造成调试器异常，甚至烧毁芯片，此外也不防水防潮。所以为何不加个透明的外衣热缩管，来点诱人的朦胧美？使用裸奔的方式，一般不会遇到打磨芯片，因为是找骂，没人会尝试。

3  笔者尝试的DIY基于以上罗列的现有产品问题和特点，总结前人经验，目前做了两种版本的硬件，经过一段时间的使用，现在使用最频繁的是加了透明外衣的TypeC版本（原谅看着脏兮兮，一直在服役），桌子上放几块开发板也不会显得很乱。身材娇小，异次元着装，一眼望去满桌子的科技感（电路板）。

首先感谢metro 的帖子和 ljbfly的帖子，以及参与讨论的众多高手。这些信息给了笔者很多启发。但是很可惜没有看到metro把东西做完善。因为从他的测试效果来看，如果测试环境都没问题的话，速度已经比肩STLinkV3（不是V2）了，也即和V3一样都达到了目标芯片支持的烧写算法的上限。最最令人惊讶的是他采用的是一颗主频只有56MHz的增强型C51单片机 CH558，最开始看到这个帖子的时候笔者没有太多留意，直到后来发现手头的类似调试器性能很差，和帖子中达到的速率相差甚远，外加ARM开放了DAPLink的源码，这才重新回过头来，结合源码来仔细分析SWD和JTAG协议和时序，最终在性能和功能上有所增强。

实际上软件移植工作在8月底就完成了，但是不想做一个不稳定的东西出来，不然徒然浪费时间，没有什么实用意义，功能强但不稳定，是不能进行大面积使用的。所以近来几个月都在公司内部大面积测试使用，发现并解决了一些小问题，整体上达到了高速和稳定并举的状态。双串口+烧写/调试同时并行使用，非常稳定。

如果有细心的网友仔细观察上图中的排针，就会发现和市面上的其他DAPLink的区别，也即是2X6而不是2X5。目前达到的功能和性能：1.经过高度优化的基于Bulk协议的DAPLink V2让性能达到STLinkV3 80%-90%，远远超过STLinkv2。烧写STM32H743，1M FLASH只需15s.(不同性能的PC对速度略有影响，但是不大。后附有完整的针对Cortex-M0+/3/4/7的各样例芯片的实测结果和用例)。2.支持Bulk版本的DAPLink V2的同时，支持HID 版本的DAPLink V1，只需要简单切换模式即可。有效兼容老版本的开发和下载软件。3.支持双路虚拟串口，这就是为何排针使用2X6的原因。双路虚拟串口可以单独设置波特率，互不影响，支持常见的固定波特率9600到230400，相当于两个USB转TTL小板，远远满足日常调试打印需求。4.同时支持SWD和JTAG协议。5.支持SWD软复位，使用SWD下载时，无需连接RST线。6.支持虚拟U盘的升级和模式切换，无需安装驱动和软件。支持升级时意外掉电防变砖。7.支持3.3V和5V供电输出，带自恢复保险丝，3V3和5V不小心接地短路不会对调试器电路造成损害。双LDO，输出3V3和MCU的3V3由独立的LDO供电，更稳定，互干扰更小。3V3可稳定对外输出150mA。5V输出由USB协议供电决定，也即500mA去掉MCU自身供电，大约40mA。(上图中是最初版本，硬件未支持双LDO)8.UART硬件兼容5V和3V3电平。9.支持STC的免冷启动下载功能。

下载速度的提升，对比较大的项目可以节约大量的下载等待时间，对于一个开发组更可观，在公司层面效率提升就更显著了，目前在调试基于STM32H743芯片的项目上下载效率提升明显。

另外为何要做双UART呢？一开始打算实现SWO协议，但是发现SWO需要占用一路UART，但是SWO并不是所有的Cortex-M都支持，它依赖于芯片内部的ITM模块，但是Cortex-M0/0+没有内置该模块，此外ITM打印过多时会丢数据，基于以上考虑，去掉SWO功能，改成更实用的两路UART，这样对于调试多UART口的MCU时更方便，不需要借助其他USB转串口小板。

支持STC免冷启动下载是他人提出的功能，感觉很有用，就加了上来。这对于初学者，比如在校生，爱好者或者同时需要开发ARM和STC单片机的开发者无疑带来了方便：抽屉里一堆下载器，找的时候又常常不见所踪。

总结，1个ELF DAPLink = 普通DAPLink+BULK高速下载+1USB转TTL小板+1STC免冷启动下载器。体积小巧，携带方便。之所以给它取名字叫ELF，意为小精灵，但人小鬼大，一个顶仨。

先唠叨这么多，看起来成长篇大论了，后面贴性能对比图，外加加速思路，分析和实现。

最近编辑记录 llinjupt (2021-12-21 23:35:10)