企业官网建设流程全解析

DAP下载器插上芯片，指示灯灭了；拔下来，灯又亮了。很多朋友把这个现象当作"下载器是不是坏了"的判断依据，实际上在源码层面，这很可能只是固件里一个状态标志位的事。ARM官方那套CMSIS-DAP参考实现，处处都藏着这种"看起来神秘、源码里理所当然"的设计。这是CMSIS-DAP源码分析连载的第二篇，上一篇把整体框架和USB HID设备层的初始化流程过了一遍，这篇直接沉到核心区域：DAP命令从哪进来、SWD时序如何一个bit一个bit地产生、缓冲区怎么流动、真实调试时又该怎么用逻辑分析仪验证自己读到的源码结论。

整个连载面向两类人：一是想搞明白DAP下载器内部工作原理的嵌入式开发者，二是打算自己移植或魔改固件、做定制调试器的朋友。读完这篇，至少你能做到：拿到任何一个基于CMSIS-DAP的源码包，能快速定位命令处理入口；遇到"连上芯片灯灭""下载失败"这类现象，不再靠猜，而是能顺着代码逻辑找到原因。

1. 从USB HID包到DAP命令管道：固件主循环怎么转起来

1.1 固件代码骨架：DAP.c、DAP_Config.h和USB驱动层的分工

CMSIS-DAP固件本质上是个"翻译器"：左边是USB，右边是SWD/JTAG。ARM官方参考实现的代码结构比较清晰，通常由三个层次组成。第一层是USB驱动层，负责处理USB枚举、HID报告收发，这一层在不同平台上的实现差异最大，有的用Keil RL-USB，有的用STM32Cube HAL，有的用LPC USB ROM驱动。第二层是DAP协议层，核心文件是DAP.c，它不关心USB底层怎么收发，只负责解析命令、执行调试协议逻辑。第三层是平台抽象层，DAP_Config.h和DAP_Config.c，把GPIO操作、延时函数、时钟配置全部封装成宏或者接口函数。

这三层之间的调用关系很简单：USB中断或主循环轮询收到一个HID报告后，把数据指针丢给DAP_ExecuteCommand，DAP.c执行完把结果写回同一个缓冲区，USB层再把缓冲区内容发回主机。这个流程在DRAM里看非常直白，但实际源码阅读时容易迷路，原因在于不同版本代码里函数名差异比较大。比如有的版本入口叫DAP_ExecuteCommand，有的叫DAP_Process，有的直接暴露DAP_ProcessCommand。读代码时先别纠结函数名，按数据流向来找：USB收数据的地方调用了一个"执行命令"的函数，这个函数就是整个协议栈的入口。

1.2 命令分发：一个switch-case撑起整个协议

打开DAP.c，你会看到核心分发逻辑其实就是一个大switch-case，或者是一个查表函数。DAP协议规定，命令包第一个字节是命令码，后面跟着参数。CMSIS-DAP v1的常用命令码我整理在下面：

不同固件版本支持的命令码不完全一样，读源码时可以通过函数开头对请求长度的判断来确认它实现了哪些命令。例如DAP_Info命令的参数很简单，但响应内容会包含协议版本号、最大包长、是否支持SWD/JTAG等信息。这部分源码读起来相对轻松，因为它只是往缓冲区里塞数据，不涉及复杂时序。

真正需要仔细看的是DAP_Transfer、DAP_SWJ_Sequence、DAP_SWJ_Pins这几个命令，因为它们会直接操作目标芯片的引脚，是底层时序的执行者。在后续章节里，我会逐个拆开讲。

2. SWD时序源码解析：bit-bang背后的时钟与数据相位

2.1 为什么官方实现选择GPIO模拟而非硬件SWD控制器

这个问题我最初读源码时也困惑过：STM32F103明明有硬件I2C、SPI，为什么调试口不用硬件控制器？原因有两点。第一是可移植性，CMSIS-DAP要跑在各种MCU上，硬件SWD控制器并不是每个MCU都有，用GPIO模拟的bit-bang方案，只要GPIO翻转速度够快，就能保证代码在不同平台间平滑移植。第二是灵活性与时序控制，bit-bang模式下，每个时钟周期的高低电平时长完全由软件控制，可以通过调整延时精确实现低速目标芯片的时序兼容，而硬件控制器通常会限制最低时钟频率，遇到一些老芯片很难适配。

但bit-bang方案也有代价：CPU占用高、速率上不去。一个1MHz的SWD时钟，意味着每秒要翻转100万次引脚，再加上数据设置、采样判断，MCU的主频至少得跑到48MHz以上才能稳定工作。这也是为什么DAP下载器普遍比独立硬件调试器慢的原因。

2.2 时钟翻转与数据稳定：一个典型写时序在源码里是什么样

SWD协议中，写操作相对简单，主机在SWCLK上升沿附近把数据逐bit放到SWDIO上。参考实现里，写一个bit的核心循环长这样（伪代码风格）：

for (i = 0; i < count; i++) { SWCLK_OUT(0); SWDIO_OUT((data >> i) & 1); SWCLK_OUT(1); }

这个循环的逻辑非常好理解：先拉低时钟，改变数据线，再拉高时钟，让目标芯片在上升沿采样。注意一个细节，数据必须在时钟拉低期间稳定，而不是在时钟高电平期间改变，否则目标芯片会采到毛刺。很多初次移植代码的人最容易犯的错误就是顺序不对，先置数据线再拉低时钟，导致数据建立时间不足。源码里虽然没有显式标注"建立时间保持时间"这些参数，但通过这个循环顺序，实际上已经实现了正确的时序关系。

关于时钟频率，DAP_SWJ_Clock命令会设置一个全局变量DAP_SWJ_Clock，然后在每次时钟翻转后调用DAP_Delay函数来实现对应的半周期延时。延时函数通常是空循环或者基于定时器的微秒延时。这里有个小坑：不同优化等级下空循环的时间差异极大，我在O0和O2优化下测过，同一段延时代码的实际延时时间能差出三倍。所以官方源码通常会在DAP_Delay里用一个volatile变量做循环计数，防止编译器优化掉延时循环。

2.3 读时序与turnaround cycle：方向切换的位置决定成败

读操作是SWD时序里比较容易翻车的地方。SWD是半双工总线，同一根SWDIO在不同阶段要切换方向。主机发出请求后，必须释放总线，让目标芯片驱动数据线返回数据。这个"主机释放总线、目标接管总线"的过渡周期叫turnaround cycle，在SWD协议里通常是1个时钟周期。

源码里这个方向的切换通常长这样：

// 发送8bit请求后 send_request_packet(); SWDIO_IN(); // 切换为输入 delay_half_clock(); delay_half_clock(); // turnaround cycle for (i = 0; i < 32; i++) { SWCLK_OUT(0); data |= SWDIO_IN() << i; SWCLK_OUT(1); } // 读完后切回输出 SWDIO_OUT(1); delay_half_clock(); // turnaround cycle

方向切换的时机非常讲究。如果切换晚了，目标芯片开始驱动数据线时，主机引脚还处于输出模式，两根驱动同时抢线，轻则读到错误数据，重则损坏引脚。如果切换早了，总线处于高阻态，目标芯片还没来得及驱动，采样时会读到不确定电平。实际源码里，turnaround cycle的位置是通过时钟翻转次数来控制的，读懂这段代码的关键是画一条时序线，把"主机输出请求-总线释放-target采样-数据返回"几个阶段标在时钟边沿上。

我在这个位置踩过坑。之前移植到一颗GPIO切换有额外延迟的MCU上，读DPIDR时经常读回0xFFFFFFFF，后来用逻辑分析仪抓波形，发现是方向切换后没有留够总线稳定时间，目标芯片数据线已经拉起来了，但MCU引脚方向还没完全切到输入。解决办法是在方向切换的宏后面加一个NOP等待，或者在切换前多插入半个时钟延时。

3. DAP_SWJ_Sequence与JTAG/SWD切换序列的实现

3.1 DAP_SWJ_Sequence逐bit输出的循环逻辑

DAP_SWJ_Sequence命令是CMSIS-DAP里一个很有用的命令，它允许主机一次性输出1到64个bit的自定义序列到SWCLK和SWDIO上。这个命令的实现很简单，就是一个逐bit驱动的循环，但它的应用场景却非常关键——所有协议切换、复位初始化序列都要靠它来完成。

源码里这段逻辑的思路是：接收一个bit位宽参数和一个数据buffer，循环这个位宽次数，每个bit同时驱动时钟线和数据线。需要注意的是，序列中数据位和时钟的对应关系，官方文档规定是LSB first还是MSB first，不同固件实现可能不同，直接决定了主机下发数据时的位序。我读过的几个参考实现里，DAP_SWJ_Sequence倾向于LSB first，即在序列中先发送数据的最低位。如果你在移植时发现目标芯片始终无法进入SWD模式，优先检查这里的位序是否正确。

3.2 初始化过程：line reset和JTAG-to-SWD切换序列如何被送出

每次DAP_Connect建立SWD连接时，固件都会执行一套固定的初始化序列。这套序列在参考实现里通常不是用DAP_SWJ_Sequence命令从主机下发，而是固件内部直接调用一个复位和切换函数。整个序列分三步：

第一步输出line reset，也就是把SWDIO拉高，同时给至少50个时钟周期。这是为了让目标芯片的SWD状态机回到一个确定的状态。第二步输出JTAG-to-SWD切换序列，根据ARM规范，这个序列是16bit的0xE79E（注意位序），连续发两遍以确保可靠切换。第三步再次输出line reset，然后往目标芯片的DPIDR寄存器发送读请求0xA5，读取IDCODE，确认SWD链路已经建立。

这套初始化逻辑在源码里往往是写死在DAP_Connect处理函数中的，而不是作为DAP_SWJ_Sequence命令的参数由主机动态下发。原因很简单，这套序列是SWD协议规定的固定内容，固件直接内置可以减少USB传输次数、缩短连接建立时间。读源码时，如果你看到一大段连续的DAP_SWJ_Sequence调用，基本就是这套初始化逻辑。

3.3 nRESET控制与连接状态指示

讲回开头的"灯灭"现象。CMSIS-DAP参考实现本身并没有强制规定LED指示逻辑，但在DAPLink这类基于CMSIS-DAP的完整固件里，LED状态切换是放在平台相关代码中的。连接状态和命令流量会改变LED的模式：没有目标连接时，固件处于idle状态，LED常亮或慢闪；当DAP_Connect命令成功建立连接、开始传输数据后，LED状态往往会切换到快闪或熄灭。

源码层面你可以这样定位：搜索LED相关的GPIO控制宏，往上回溯是哪个函数在调用它。以DAPLink为例，状态机的核心驱动函数是LED_update，它根据一个连接状态标志和命令接收计数来决定LED的亮灭、闪烁模式。主机连接上芯片后灯熄灭，往往是因为进入了"active"状态，设计者用常亮和熄灭两种状态区分"空闲待连接"和"正在调试"。所以从源码角度看，灯灭不是故障，而是固件在告诉你"我已经和芯片建立连接了"。反过来，如果拔掉芯片灯恢复亮，说明固件检测到目标端异常或连接被断开，状态机回到了idle。

当然，实际操作中也存在因为目标芯片短路、供电异常导致MCU被拉死、程序跑飞进而影响LED的情况，但那些属于硬件故障范畴，和源码逻辑无关。遇到灯灭问题，先看是不是正常的状态切换，再考虑硬件层面。

4. 缓冲区与传输控制：64字节HID包的性能瓶颈

4.1 收发共用一个缓冲区的设计逻辑

CMSIS-DAP参考实现里有一个核心数据结构：一个大数组当作DAP缓冲区，USB接收到的原始请求和要发送的响应，共用这一块内存。源码中通常是一个静态数组，大小由DAP_PACKET_SIZE宏控制。这种收发共用的设计看起来有点危险，但实际运行中不存在数据冲突，因为执行流程是串行的：USB收到包，DAP_ExecuteCommand处理，处理完立即在同一个缓冲区里生成响应，USB发送完成之前不会触发新一轮接收。

这个设计最大的好处是节省内存，对于很多只有几KB RAM的MCU来说很重要。坏处是如果需要缓存多个待处理的命令，就不得不引入额外的队列机制。CMSIS-DAP v2协议增加DAP_Queue相关命令，就是为了解决"主机连续下发命令、固件串行处理"时的吞吐瓶颈问题。

4.2 DAP_Transfer与批量传输的合并逻辑

DAP_Transfer命令已经支持一次携带多个DP/AP寄存器的读写请求，响应也是按顺序一一对应。但在HID 64字节包的限制下，单次传输最多只能装下几个寄存器操作，这直接限制了有效带宽。DAP_TransferBlock的作用则是进一步把大量数据（比如Flash编程）打包成一个大块传输，减少USB事务的次数。

源码层面，DAP_TransferBlock的处理逻辑比DAP_Transfer复杂一些。对于写操作，它直接从请求包中提取数据，逐bit驱动SWD时序；对于读操作，它读取目标寄存器数据后放入响应缓冲区。这个函数内部经常有性能优化的痕迹，比如将循环展开、使用更快的IO操作函数替代通用的GPIO库函数。读这段代码时不要过于纠结具体的优化技巧，把注意力放在数据指针的移动上：请求指针不断向后，响应指针不断向前，最终统计实际传输的字节数并更新到响应包的长度字段里。

4.3 从HID到bulk：CMSIS-DAP v2的高速化改造

HID 64字节包是CMSIS-DAP v1时代最大的性能瓶颈。USB全速设备每帧1ms传输一次，每次最多64字节，理论极限只有64KB/s，实际有效数据率还要打个七折。这就是为什么很多人在使用DAP下载器烧写大容量的固件（比如几MB的App镜像时），进度条跑得让人心焦。

CMSIS-DAP v2协议引入了自定义bulk端点来替代HID传输。bulk传输可以使用更大的包长度（全速下64字节，高速下512字节），并且可以利用USB协议的连续传输机制大幅提升吞吐量。源码方面的变化是增加了DAP_Queue_Info、DAP_Queue_Extension等命令，以及一个真正意义上的命令队列。主机可以一次性下发多条命令，固件把它们缓冲下来，逐个执行后将结果批量返回。实测中，同样是STM32F103作为下载器MCU，改造为v2 bulk模式后，Flash编程速度可以从20KB/s左右提升到100KB/s以上，体感差距非常大。

如果你打算自己改造固件，重点关注的参数是DAP_PACKET_SIZE。在HID模式下它一般设置为64，但切换到bulk模式后，可以把这个值调大到512甚至1024，同时需要确保USB描述符里对应的端点大小一致，否则USB枚举会直接失败。

5. 源码之外：用逻辑分析仪验证波形与排查实际故障

5.1 接线与触发配置

读源码是一回事，确认自己读懂了是另一回事。我的习惯是：每读懂一段时序代码，就上逻辑分析仪抓一次实际波形，对照着看。手上只要有最常见的8通道24MHz采样率的逻辑分析仪就够用了。接线很简单，SWCLK接一个通道，SWDIO接一个通道，GND共地。触发条件设置为SWCLK下降沿，采样率至少设为10MHz以上，否则测量时钟周期会有很大误差。

对于SWD这种低速总线，注意逻辑分析仪探头不能太长，杜邦线控制在10cm以内，否则线间电容会导致边沿变缓，抓出来的波形边沿位置和你实际看到的源码时序可能对不上。

5.2 用源码推导波形，再用波形反推源码行为

实际操作时，我会先做一个预测：根据源码里的循环逻辑，推算出某个命令应该产生的波形特征。比如DAP_SWJ_Sequence命令发一个8bit序列0xA5，预期波形就是8个时钟脉冲，每个脉冲的上升沿位置对应一个数据位。然后用主机端工具（比如pyOCD或OpenOCD）发送对应命令，同时用逻辑分析仪抓取。如果波形和预期一致，说明源码理解正确；如果不一致，就说明中间某些环节和设想不同，这时候顺藤摸瓜排查。

这个方法特别适合排查"连接不上目标芯片"类问题。比如之前我调试一块STM32F103目标板，DAP下载器连接时总是报错。用逻辑分析仪抓DAP_Connect时序后发现，line reset的50个时钟周期竟然少了十几个，原因是我在移植时修改了延时函数，导致时钟翻转过程中的延时不一致。这种问题看源码很难发现，但波形上一眼就能看出来。

5.3 实测一次连接建立失败：从现象到源码的完整排查链路

再用一个具体案例说明排查方法论。现象：DAP下载器插上目标板后，OpenOCD报"Could not read IDCODE"。

第一步，先用逻辑分析仪抓SWCLK和SWDIO两条线，看DAP_Connect命令执行时是否输出了完整的初始化序列。如果连序列都没有，说明USB命令压根没到达固件或固件没执行到连接逻辑，问题在USB层或命令分发层。第二步，如果看到了line reset和切换序列但IDCODE读回全是1，说明SWDIO方向切换或数据采样有问题。此时把波形放大，逐个时钟核对数据位与源码中turnaround cycle的位置。第三步，如果波形看起来完全正常但还是读不到IDCODE，就要怀疑目标芯片供电、复位引脚拉死等硬件问题了。

我实际遇到过一种情况，波形完全正常，但目标芯片就是不回应。后来发现是板子上有另一个外设把SWDIO也拉住了，导致总线被占用。这种问题已经超出源码范畴，但排查方法仍然是从波形出发，验证总线状态是否正常。逻辑分析仪的价值就在于此，它能帮你区分问题出在"固件没发对"还是"目标没回应"。

一些移植和改造的实用建议

最后聊点直接能用的经验。如果你打算把CMSIS-DAP固件移植到自己的板子上，我这几条建议尤其重要。

第一，动手之前先确认GPIO初始化是否正确，重点看封装在DAP_Config.c里的引脚复用配置。SWDIO需要的引脚模式是"推挽输出"和"浮空输入"之间动态切换，很多MCU的GPIO模式切换有额外延迟，必须在方向切换后加一点延时，否则turnaround cycle会不稳定。第二，时钟频率别急着调高。先用100kHz确认链路稳定，再逐步提升，每次提一档都跑一次IDCODE读取验证，这样能快速找到稳定的上限频率。第三，如果目标是STM32F103这类芯片，下载失败时先检查Boot1引脚和供电，IDCODE读不到时优先怀疑目标芯片没进入正常运行状态，而不是一上来就怀疑DAP固件。

说到具体操作，调试DAP固件时，在USB主循环里加一个简单的计数变量，每收到一个HID包就加一，然后用调试器看这个值的变化，能快速确认USB通信是否正常。这个方法虽然土，但比任何高级工具都直观。

这次源码分析的核心内容就到这里。DAP固件读起来并不难，难的是把协议层、平台层、时序执行三层逻辑串联起来理解。你如果有条件，建议手边放一个逻辑分析仪，每读一段代码就实测一下，收获会比干读源码大很多。下一篇如果有时间，我会拿一个具体的下载器固件工程，完整走一遍从USB枚举到Flash烧写全流程的代码路径，到时候见。