从D+上拉到CDC数据通路：USB主机枚举与抓包避坑

简介：这份面向嵌入式开发者的 USB Host 驱动 CDC 设备技术文档，聚焦于 MCU 直接识别并读写 USB 串口转接仪器时遇到的实际问题，帮助读者打破传统 RS232 接口的限制；适合具备一定 USB 基础、希望深入理解协议细节与主机端实现的中高级工程师。资料包体简洁，含 1 个 PDF 文件，压缩包约 4.12MB，便于集中阅读和随时查阅；已有 2667 人学习，在 USB 主机开发方向具有较高参考价值。文档从插入检测、总线复位讲起，梳理差分 NRZI 编码、SYNC 同步域、SOP/EOP、PID 类型、帧号与标准请求结构，并结合 CH32V307 平台及 Bus Hound、SSCOM、DSView、USB Packet viewer 等工具，还原以 0 地址获取设备描述符、Set Address、读取配置、接口和端点描述符，直至确认 CDC 类并建立双向通信的流程。读者可掌握 USB 通信时序、抓包解包方法与 CDC 设备枚举要点，为实际项目中的 USB Host 串口通信开发提供可复用的分析思路与排错依据。

1. 一根上拉电阻定生死：USB Host 认出 CDC 设备的起点

大多数人以为 USB HOST 识别一台 CDC 类设备靠的是“读描述符”，但真正的判决发生在插头接触的那一瞬间：D+ 被 1.5kΩ 上拉电阻拉高的那一刻，主机就已经知道“来了一个全速或高速设备”。后面所有的复位、分配地址、读描述符，都只是在为这个判决补充证据。顺序一旦理解反了，排查故障时就会一直盯着描述符看，而真正的线索其实躺在波形里，这就是为什么做 USB 协议分析，第一件事永远是先看 D+/D- 的电平，而不是急着解包。这篇内容围绕一条完整的“插入 → 复位 → 编码对齐 → 枚举 → 数据通路”链路，把主机侧每一步为什么这么设计、代码里怎么落地讲透。

2. 从电平到比特：插入检测、总线复位与 NRZI 编码

2.1 D+/D- 上拉电阻：速度的第一次判决

主机端 D+ 和 D- 各挂一个 15kΩ 下拉电阻，所以总线上没有设备时，两根线都被拉到低电平。设备端则在上拉一侧做文章：全速和高速设备在 D+ 上挂 1.5kΩ 上拉，低速设备在 D- 上挂。逻辑分析仪抓到的波形非常干净——插入前 D+、D- 都是低，插入后 D+ 变高、D- 仍低。主机就是靠这个电平差判断“有设备接入，且是全速或高速类别”。

这里有个容易忽略的细节：高速设备并不是一上来就跑高速。它先以全速设备的电气身份出现（D+ 上拉），主机按全速流程复位，然后双方通过一对 chirp K/J 握手确认“都支持高速”，才切换到高速模式。所以在逻辑分析仪上，高速设备的第一个复位脉冲看起来跟全速设备一模一样，真正的分叉点在后头。常见的实现思路是：主机控制器在复位期间检测 chirp 序列，检测到就切到高速 PHY，检测不到就留在全速。

空闲状态在协议里叫 J 状态。全速设备 J 状态是 D+ 高、D- 低；低速设备反过来。这个定义后面讲 SOP 时会直接用到，因为“包的开始”就是用“从 J 驱动到相反状态”来标记的。

2.2 总线复位：为什么必须是 10ms，而不是随便拉一下

USB 协议规定，D+ 和 D- 同时被拉低并保持 10ms 以上，代表一次总线复位。注意这里说的是“同时拉低”，也就是 SE0 状态。差分信号虽然靠两根线的电压差传数据，但复位这种全局动作是可以单端控制的——主机直接把两根线都压到低电平就行，不需要考虑差分极性。

为什么是 10ms 这个量级？因为它要覆盖足够多的位时间，让任何速度、任何状态的设备都能稳定检测到，同时又不至于长到让整条总线停顿太久。复位对设备意味着什么：地址回到 0、配置回到 0、端点状态清零、DATA0/DATA1 翻转位复位。换句话说，复位是主机手里唯一能强制把设备拉回可控初始态的手段。

素材里的抓包记录显示，桌面系统的主机栈在枚举一个设备时会复位不止一次：第一次复位后，主机用 0 地址向设备要 8 字节设备描述符；然后可能再复位一次，接着才发 Set Address，把设备地址从 0 改成实际值。为什么要这么绕？因为复位之后总线上所有设备地址都是 0，此时只能有一个设备在线，主机可以安全地用 0 地址跟“唯一那个设备”对话。先摸清它的端点 0 最大包长，再分配地址，逻辑上才安全。

2.3 NRZI 编码与位填充：没有时钟线，采样点靠什么对齐

USB 只有 D+ 和 D- 两根数据线，没有独立的时钟线。接收端要正确采样，就必须从数据本身恢复时钟，这就是 NRZI 编码的用意。规则只有两条：遇到 1 不翻转电平，遇到 0 翻转电平。差分信号负责抗干扰，NRZI 负责把时钟信息编码进跳变里。

问题来了：如果数据里出现一长串 1，电平一直不翻转，接收端就没有边沿可用，时钟会漂。协议给的解法是位填充——连续出现 6 个 1 之后，发送端强制插入一个 0，接收端在连续 6 个 1 之后自动丢弃紧随的那个 0。这是硬件层做的事，软件完全无感，但调试时如果发现解出来的比特流莫名其妙多一位，第一嫌疑就是位填充没处理好。

同步域是另一个精巧设计。每个包开头都有一个 SYNC 域，全速和低速是 0000 0001，高速是 31 个 0 后面跟一个 1。因为遇 0 翻转，这串 0 会在总线上产生连续 7 次（或 31 次）跳变，接收端就用这段时间把本地时钟频率锁到发送端上。等 SYNC 结束，采样点已经对齐，接下来收到的每一位都能稳定判读。这也是为什么抓包时永远先看 SYNC 的方波是否规整——方波变形，后面全错。

2.4 SOP、EOP 与包的边界

包与包之间靠电平约定分隔。总线空闲时处于 J 状态；主机把线驱动到相反状态（K 状态），这个跳变就是 SOP，包开始的标志。包的结尾是 EOP：D+ 和 D- 同时为低，保持两个比特时间，然后回到 J 状态。

这里有一个初学者经常混淆的点：EOP 的 SE0 和复位的 SE0 是同一个电平状态，区别只在持续时间。EOP 是两个位时间，复位是 10ms 以上。用逻辑分析仪看的时候，如果看到一段 SE0 分不清是包尾还是复位，量一下宽度即可，这是硬件层最直接的判据。抓包软件能把这两者区分开，靠的也是同一个判据。

把四层串起来看：上拉电阻决定“有没有设备、什么速度”，复位把设备拉回 0 地址初始态，NRZI 加位填充解决“没有时钟线怎么采样”，SOP/EOP 划出包的边界。这四层全部是物理和链路层的事，跟描述符一点关系都没有——这也是为什么一上来就盯着描述符解包，往往找不到问题的根因。

3. 包与事务：一次完整枚举被拆成几百个字节

3.1 PID、地址、端点、CRC 与帧号

每个包的结构是固定的：SYNC 之后紧跟 PID，然后是具体内容，最后是 CRC。PID 占一个字节，低 4 位是类型，高 4 位是这 4 位的按位取反，作为校验。比如 SETUP 的类型码是 1101，取反得 0010，拼起来就是 0x2D；IN 是 1001，取反 0110，拼成 0x69；OUT 是 0001，取反 1110，拼成 0xE1。这 8 位互补校验让接收端能在一位出错时立刻发现，代价极小。

PID 分四类：

令牌包里还带 7 位设备地址和 4 位端点号，所以一条总线上最多 128 个地址、每个设备最多 16 个端点。地址 0 是复位后的默认地址，正式地址由主机分配。CRC5 保护令牌包，CRC16 保护数据包，长度不同是因为令牌包短、数据包长，校验强度和开销要平衡。

帧号域是 11 位，只出现在 SOF 包里，从 0 递增到 0x7FF 后翻转。全速设备每 1ms 一帧，高速设备每 125μs 一个微帧，主机启动后就不停地发，永不间歇。有人会问：Bulk 传输又不等时，帧号有什么用？用处在于时间基准——主机的调度、超时重试、等时传输的带宽分配，全都挂在这个节拍上。

3.2 第一包 SETUP：只要 8 字节，是保守还是必然

复位完成后，主机以 0 地址发出第一个 SETUP 事务。8 字节数据是：

80 06 00 01 00 00 40 00

逐字节拆：0x80 是 bmRequestType，最高位 1 表示数据方向是设备到主机，次高位 00 表示标准请求，最低 5 位 0 表示接收者是设备本身。0x06 是 bRequest，GET_DESCRIPTOR。0x0100 是 wValue，高字节 01 表示要的是设备描述符，低字节 00 是索引。0x0000 是 wIndex。0x0040 是 wLength，名义上要 64 字节。

但主机实际只取回 8 字节，返回内容是：

12 01 00 02 00 00 00 08

0x12 是 bLength，即设备描述符全长 18 字节；0x01 是 bDescriptorType，设备描述符；0x0200 是 bcdUSB，小端表示 USB 2.00；接下来三个 0x00 分别是 bDeviceClass、bDeviceSubClass、bDeviceProtocol；0x08 是 bMaxPacketSize0，也就是端点 0 的最大包长。

注意一个常见的读图误区：很多人第一眼会把“02 00”当成设备类字段，其实那是 bcdUSB 的位置，设备类字段在后面三个字节。之所以要读这 8 字节，恰恰是因为此时主机还不知道设备端点 0 能收多大的包。8 字节是协议规定所有设备必须支持的最小值，先用它把 bMaxPacketSize0 问出来，后续通信才能按正确的包长走。这是典型的“先问最小信息、再按信息办事”的保守设计。

3.3 Set Address：地址切换的时机是个陷阱

拿到端点 0 包长后，主机发 Set Address，把设备地址从 0 改成实际值：

00 05 12 00 00 00 00 00

0x00 是 bmRequestType，方向主机到设备、标准请求、接收者设备；0x05 是 SET_ADDRESS；0x0012 是 wValue，新地址 18；wIndex 和 wLength 都是 0。设备收到后不回数据，主机发一个 IN 令牌，设备回一个长度为 0 的 DATA1 包，表示“状态阶段完成”，整个请求才算结束。

这里的坑在于地址生效时机：新地址必须在状态阶段成功完成后才生效。如果设备提前切地址，主机后续的令牌包就会打到空处；如果主机在状态阶段完成前就用新地址发令牌，同样会失败。抓包里表现为 Set Address 之后突然全部超时，设备像消失了一样，十有八九是这一位没对齐。

3.4 完整描述符与配置、接口、端点

地址切好之后，主机重新发 GET_DESCRIPTOR，这次要 18 字节：

80 06 00 01 00 00 12 00

返回的是完整设备描述符：

12 01 00 02 00 00 00 08 03 04 01 60 00 06 01 02 03 01

前 8 字节与第一次一致，后 10 字节补上了 VID（0x0403）、PID（0x6001）、bcdDevice（0x0600）、厂商字符串索引、产品字符串索引、序列号索引和配置数量。至此主机才真正知道对面是谁。

接着是 GET_DESCRIPTOR 配置描述符。主机第一轮只取 9 字节，为的是读出 wTotalLength，因为配置描述符后面还挂着一串接口描述符和端点描述符，总长度不固定。拿到总长后再完整读一遍，这时数据量超过端点 0 的单包容量，会在总线上看到多组 IN 事务分包返回，每包都用 DATA0/DATA1 交替标记。

配置描述符里最关键的三项：wTotalLength、bNumInterfaces、bMaxPower。bMaxPower 的单位是 2mA，如果读到 0x16，就是 22×2=44mA，也就是说这个设备从总线取电不超过 44mA。接口描述符给出 bInterfaceNumber、bNumEndpoints 和类信息，端点描述符则给出方向、传输类型和包长。

素材里那台设备最终解析出两个 Bulk 端点：IN 端点地址 0x81，最大包 64 字节；OUT 端点地址 0x02，最大包 64 字节。地址最高位是方向位，1 表示设备到主机，低 4 位是端点号。Bulk 类型的含义是“尽力传输、有校验、可重传”，不占固定带宽，这对串口数据流这种突发性强的场景正合适。枚举走到这一步，链路已经建立，剩下的就是往这两个管道里灌数据。

4. CDC 数据通路：枚举完成之后才是真正的活

4.1 类请求：CDC 设备不是“插上就能收字节”

枚举只解决了“设备是谁、有哪些端点”，并没有解决“设备愿不愿意开始传数据”。对 CDC 类设备来说，这一步靠类请求完成。最常见的两个：

• SET_LINE_CODING，bmRequestType 为 0x21（主机到设备、类请求、接收者接口），bRequest 为 0x20，后面跟 7 字节数据：4 字节波特率、1 字节停止位、1 字节校验方式、1 字节数据位。这 7 字节就是“串口参数”在 USB 上的等价物。
• SET_CONTROL_LINE_STATE，bmRequestType 同样是 0x21，bRequest 为 0x22，wValue 的低两位分别对应 DTR 和 RTS。

很多串口转 USB 设备在收到 SET_CONTROL_LINE_STATE、且 DTR 被拉高之前，会拒绝在 Bulk IN 端点上返回数据。表现就是枚举全对、抓包也看不到错误，但读数据永远返回 NAK 或者干脆没反应。这不是协议 bug，而是设备在模拟“串口没被打开”的状态。

这里必须说清一个事实：真正的 CDC 规范里还有中断端点用于上报串口状态，但市面上大量“串口转 USB”芯片用的是厂商自定义接口类（bInterfaceClass 为 0xFF），只保留两个 Bulk 端点，把参数配置简化成几条类请求。主机端写驱动时，如果只按标准 CDC 去匹配接口类，就会找不到这类设备。稳妥做法是两种都认：接口类是 0x02 走标准 CDC 流程，是 0xFF 就按两个 Bulk 端点当纯数据管道处理。

4.2 端点缓冲、NAK 与数据翻转

Bulk 传输的事务结构是：主机发 IN 令牌，设备如果手里有数据，回一个 DATA0 或 DATA1 包，主机回 ACK；设备如果暂时没数据，回 NAK，主机过一会儿再问。NAK 不代表出错，它只是“我现在忙”，主机必须能忍受这种轮询，不能把它当失败直接放弃。

DATA0 和 DATA1 的交替是另一层保险。每个端点独立维护一个翻转位，成功传输一次翻转一次。如果主机回了 ACK 但设备没收到，设备会重发同一个包，主机凭翻转位判断“这是重传，丢掉”。这就是 USB 在不可靠物理层上做可靠传输的方式，代价只是一个比特的状态。

主机发送方向同理：OUT 令牌带数据下去，设备回 ACK/NAK/STALL。STALL 才是真错误，表示端点被挂起或者请求不被支持。写主机端代码时，NAK 要重试、STALL 要清端点、ACK 才推进状态机，这三条分支少一条都会在真机上出问题。

4.3 主机侧代码：SETUP 构造、描述符解析与状态机

先看控制传输的请求结构。协议定义的 8 字节 SETUP 包，在代码里就是一个紧凑结构体：

#include <stdint.h> /* 8 字节 SETUP 包，必须按 1 字节对齐，直接喂给主机控制器 */ typedef struct __attribute__((packed)) { uint8_t bmRequestType; /* bit7 方向: 1=设备到主机; bit6:5 类型: 0标准 1类 2厂商; bit4:0 接收者 */ uint8_t bRequest; /* 请求码，如 0x06=GET_DESCRIPTOR, 0x05=SET_ADDRESS */ uint16_t wValue; /* 含义随请求变化，GET_DESCRIPTOR 时高字节是描述符类型 */ uint16_t wIndex; /* 通常为接口号或 0 */ uint16_t wLength; /* 期望传输的字节数，0 表示无数据阶段 */ } usb_setup_t; /* 构造一个 GET_DESCRIPTOR 请求，返回实际写入的字节数 */ static void build_get_descriptor(usb_setup_t *s, uint8_t type, uint8_t index, uint16_t len) { s->bmRequestType = 0x80; /* 设备到主机 + 标准 + 设备 */ s->bRequest = 0x06; /* GET_DESCRIPTOR */ s->wValue = (uint16_t)((type << 8) | index); /* 高字节类型，低字节索引 */ s->wIndex = 0x0000; s->wLength = len; /* 第一次传 8，第二次传 18 */ }

这段代码的价值不在语法，而在参数语义。wValue 的高字节是描述符类型、低字节是索引，这个位域约定如果写反，设备会返回 STALL 或者干脆返回错误的描述符。wLength 第一次必须填 8 而不是 64，因为此时端点 0 的包长还是未知数；填大了设备可能按自己的包长截断，主机收到的长度就和预期对不上。

描述符解析同样是位域活。设备描述符 18 字节、配置描述符 9 字节、接口描述符 9 字节、端点描述符 7 字节，长度固定但顺序可变，正确做法是按 bLength 逐段跳：

/* 遍历配置描述符集合：从 9 字节配置头开始，按 bLength 逐段前进 */ static void parse_config_block(const uint8_t *buf, uint16_t total) { uint16_t off = 0; while (off + 2 <= total) { uint8_t len = buf[off]; /* 当前描述符总长 */ uint8_t type = buf[off + 1]; /* 1=设备 2=配置 4=接口 5=端点 */ if (len == 0) break; /* 防御：长度 0 会导致死循环 */ switch (type) { case 0x04: /* 接口描述符：off+2 接口号, off+4 端点数, off+5 接口类 */ break; case 0x05: /* 端点描述符：off+2 地址(bit7 方向), off+3 属性, off+4 包长 */ break; default: break; } off += len; /* 关键：永远按 bLength 跳，不按固定偏移 */ } }

这段循环的关键在最后一行：绝不能假设“配置描述符后面固定接接口描述符”。设备可能插入厂商自定义描述符，跳过它们的唯一办法就是读 bLength 累加。另外那个len == 0的防御不是多余的——缓冲区截断时读到 0 长度，没有这行判断就是死循环，调试时表现为程序卡死、抓包一切正常。

主机侧枚举则是一个显式状态机，每一步只做一件事：

typedef enum { HOST_IDLE, /* 等待 D+ 上拉 */ HOST_RESET, /* 拉低 SE0 保持 10ms */ HOST_GET_DEV8, /* 0 地址读 8 字节设备描述符 */ HOST_SET_ADDR, /* 分配地址，等待状态阶段完成 */ HOST_GET_DEV18, /* 用新地址读完整设备描述符 */ HOST_GET_CFG, /* 先读 9 字节拿 wTotalLength，再读全量 */ HOST_SET_CONFIG, /* SET_CONFIGURATION 选中配置 1 */ HOST_CDC_INIT, /* SET_LINE_CODING + SET_CONTROL_LINE_STATE */ HOST_READY /* 进入 Bulk 收发循环 */ } host_state_t;

状态机每一格都对应抓包里可见的一段事务，出问题时能直接定位到“卡在哪个状态”。把枚举写成一个大函数一口气跑完，短时间看是省事，真出问题时就是黑匣子：你不知道是超时了、NAK 了还是 STALL 了。这套拆分是我见过最实用的调试习惯。

5. 抓包避坑：五个只有逻辑分析仪才能告诉你的翻车现场

5.1 插入后主机毫无反应，波形上 D+ 一直是低

现象：设备插上，主机侧状态机停在 HOST_IDLE，软件解包看不到任何令牌包，逻辑分析仪显示 D+ 始终低电平。

原因：设备端上拉电阻没有供电，或者这本来就是个低速设备、上拉挂在 D- 上，而主机只监测 D+。还有一种可能是线材只接了电源没接数据，劣质转接线里这种情况并不少见。

解决：先用万用表量 D+ 对地电压，插入后应当接近 3.3V。如果一直是 0，换线、换设备交叉验证。这条排查放在最前面，因为它是唯一一条完全不需要协议知识的检查，却经常被人跳过。

5.2 复位后设备不响应 SETUP，或者一直回 NAK

现象：抓包能看到复位脉冲，主机接着发 SETUP 令牌，但设备不回数据包，或者只回 NAK。

原因有三类：复位持续时间不足 10ms，设备没来得及完成内部初始化；设备供电不足，尤其是总线取电较大的设备；设备固件在等待某个初始化条件，比如外部晶振稳定。

解决：先量复位脉冲宽度，必须大于 10ms；再量 VBUS 电压在插入瞬间是否塌陷；最后换一个已知能工作的主机环境做对照。注意 NAK 和“完全没响应”是两回事：NAK 说明设备活着、只是没准备好，这种情况优先怀疑固件初始化时序，而不是电气问题。

5.3 Set Address 之后所有事务超时，设备像消失了

现象：Set Address 的 SETUP 阶段正常，状态阶段也收到了零长度包，但紧接着用新地址发的令牌包全部无响应。

原因：地址生效时机错了。设备在状态阶段完成之前就切换了地址，或者主机在状态阶段还没结束时就改用新地址发送。另一种可能是新地址与总线上已有设备冲突。

解决：抓包里重点看状态阶段那个零长度 DATA1 包有没有被主机 ACK。只有在它之后，双方才可以切地址。如果时序没问题还是失败，把新地址换成一个没用过的值再试，排除地址冲突。

5.4 描述符读完长度对不上，或者校验错

现象：GET_DESCRIPTOR 返回的数据长度小于 wLength，或者解析出来的字段明显不合理（比如 bLength 是 0）。

原因：wLength 给得比端点 0 的包长大，设备的响应被截断；或者主机在分包接收时没有正确维护 DATA0/DATA1 翻转，导致中间某个包被当成重传丢弃。

解决：第一次读描述符永远只读 8 字节，拿到 bMaxPacketSize0 之后再按这个值对齐读取。分包接收时每个包都要校验翻转位，收到重复包直接丢弃但不要中断流程。这类问题在软件解包工具里通常表现为“数据少了几个字节”，很容易被误判成设备固件 bug。

5.5 枚举全对，但 Bulk 一发数据就 STALL 或者收不到

现象：所有描述符读取正常，端点也识别出来了，但主机往 Bulk OUT 写入后，设备返回 STALL；或者主机 IN 轮询一直拿不到数据。

原因：漏了 CDC 类请求。很多设备要求先发 SET_LINE_CODING 设置参数、再发 SET_CONTROL_LINE_STATE 拉高 DTR，才认为“串口被打开”。在这之前，Bulk 端点处于关闭状态，返回 STALL 或者对 IN 一直 NAK 都是正常行为。

解决：枚举完成后固定插入这两条类请求，顺序是先 SET_LINE_CODING 后 SET_CONTROL_LINE_STATE。如果设备是厂商自定义接口类，可以先跳过这两步直接试 Bulk；一旦遇到 STALL，再回头补上，用二分法确认到底哪条请求是必需的。血泪经验是：别假设所有 CDC 设备的行为一致，抓包看设备到底在哪一步开始“松口”。

6. 设计取舍：把复杂度留在主机侧，设备侧才能便宜

回头看整条链路，会发现一个贯穿始终的设计倾向：复杂度几乎全部堆在主机侧。上拉电阻只用一个比特告诉主机“我是什么速度”；复位由主机发起、时长由协议规定；时钟恢复靠发送端插 0、接收端自己算；枚举顺序、地址分配、包长协商，全部由主机决策。设备端要做的只是“老实回答”，成本被压到极低——这正是 USB 能把接口芯片做到几分钱一片的根本原因。

这个取舍也解释了为什么先读 8 字节而不是一次读全。主机在不知道对方端点包长的时候，任何多余的读取都可能被截断；用协议规定的最小值 8 探一次路，代价是两三次事务，换来的是后续所有通信都建立在确定参数上。两次复位、地址 0 独占，也是同一套思路：宁可多花几毫秒把状态清干净，也不在不确定的总线状态上冒险。

代价当然有。主机侧要维护端点状态、翻转位、NAK 重试、超时计数，代码量比“打开串口读字节”大一个数量级；调试时还必须同时掌握物理层波形和协议层语义，只看一头就会翻车。我一般的做法是：任何一次新设备接入，先用逻辑分析仪确认 D+ 上拉和复位宽度，再用软件解包看枚举事务，最后才对数据通路下结论。三层都过一遍，比在代码里加十个打印都管用。

从那以后，我每次接新设备，都强制先跑一遍“上拉电平 → 复位宽度 → 前三个 SETUP 包”这条最小验证链，再动手写业务代码。这份资料把插入检测、编码方式、包结构、枚举时序和数据通路完整串成了一条线，波形与字节对照着看，比自己啃规范快得多。希望帮到你。

本文还有配套的精品资源，点击获取