1. USB Descriptor 概述与 PD 调试背景
1.1 什么是 USB Descriptor？
说实话，很多做 PD 的工程师，天天和电压电流打交道，但一提到 Descriptor，就觉得这是枚举的事，跟自己没关系。我以前也这么想，直到有一次，一个 Type-C 转 HDMI 的方案死活跑不通，抓了整整两天的 PD 日志，最后发现是 Descriptor 里的“VDO”字段写错了。嗯，从那以后，我再也不敢小看这玩意儿了。
USB Descriptor，说白了就是 USB 设备的“身份证”。你想想看，一个设备插到电脑上，电脑怎么知道你是谁？支持什么协议？能输出多少电压？它不是靠猜的，而是靠一套标准化的数据结构——Descriptor。这套结构由 USB-IF（USB Implementers Forum）定义，所有 USB 设备都必须遵守。
在 PD 调试场景下，Descriptor 的作用更加关键。PD 协议本身只负责协商电压和电流，但到底协商成 5V 还是 20V，供电能力是多少，这些信息都藏在 Descriptor 里。
核心观点： Descriptor 是 USB 枚举和 PD 协商的信息基础。没有正确的 Descriptor，再好的硬件方案都是白搭。
1.2 Descriptor 的层级结构
USB Descriptor 不是散乱的数据包，它有严格的层级关系。我习惯把它理解为一棵树：根是设备描述符，往下分配置描述符，再往下是接口描述符和端点描述符。每一个层级，都回答一个具体的“问题”。
- 设备描述符（Device Descriptor）： 回答“你是谁？”——包含 VID/PID、USB 版本号、设备类别等。
- 配置描述符（Configuration Descriptor）： 回答“你有哪些能力？”——供电电流、接口数量等。
- 接口描述符（Interface Descriptor）： 回答“你提供什么功能？”——音频、视频、HID 等。
- 端点描述符（Endpoint Descriptor）： 回答“数据怎么传？”——端点类型、传输方向、包大小。
- BOS 描述符（BOS Descriptor）： 这是 USB 3.0 以后引入的，专门用来扩展描述能力，PD 里经常用到它来携带 VDO。
举个例子，我在调试一个支持 PD 的移动电源时，插到电脑上没反应。用 Bus Hound 抓一看，设备描述符的 bcdUSB 字段写的是 0x0200（USB 2.0），但这个移动电源明明支持 USB 3.0 和 PD。改回 0x0300 后立刻识别成功。所以，别小看任何一个字节。
1.3 Descriptor 在 PD 协商中扮演什么角色？
PD 协商的过程，本质上是一个“询价→报价→确认”的过程。但询价的前提是，双方得知道对方能干什么。这个“能干什么”的信息，很大一部分来自于 Descriptor。
具体来说，PD 协议里有几个关键概念和 Descriptor 直接相关：
| PD 概念 | 对应的 Descriptor | 我遇到过的问题 |
|---|---|---|
| 供电能力（PDO） | BOS Descriptor → ID Header → VID/PID | 某 Hub 的 5V PDO 电压设为 5.2V，设备认为超范围拒充 |
| 可选模式（Alternate Mode） | BOS Descriptor → Vendor Defined Payload | DisplayPort 模式进不去，因为 VDO 里的 UFP 掩码写反了 |
| 充电协议 BCS | 配置描述符 → bMaxPower 字段 | 用这个字段判断设备是否支持快充，但很多方案根本不更新它 |
| 供应商信息 | 设备描述符 → iManufacturer / iProduct | 测试工具靠字符串描述符识别不同供应商的调试接口 |
注意： 很多工程师只关注 PD 协议层的 SOP 消息，忽略了 Descriptor 的验证。但实际上，Host 端（比如笔记本）在建立 PD 连接之前，会先读一遍设备的 BOS 描述符。如果 BOS 里的 VDO 格式不规范，PD 协商根本不会启动。
1.4 调试中的“隐藏杀手”：Descriptor 错误导致的 PD 失败
我总结了几个调试中常见的 Descriptor 问题，你想想看，是不是都遇到过：
- VID/PID 冲突： 同一个公司有多个产品，但 VID/PID 写的一样。PC 端驱动识别错乱，PD 协商停留在 SRC Capabilities 不往下走。
- bMaxPower 误导： 有的设备虽然支持 60W PD，但配置描述符里 bMaxPower 还写的是 100mA。Host 端认为自己可能带不动，主动降级到 5V/500mA。
- BOS 缺失： 老平台迁移到 USB 3.1 后，忘记添加 BOS 描述符。设备枚举正常，但 PD 从来不发 Source Capabilities。
- VDO 格式错误： 这是重灾区。我 debug 过一个 4K 扩展坞，VDO 里的 Manufacturer_Specific 字段少了一个字节，导致 Host 读取失败，PD 协商回退到 5V。
曾经我花了一整个下午排查一个 PD 握手失败的问题，所有 SOP 消息都正常，逻辑分析仪也看不出异常。最后用 USBTreeView 读了一遍 Descriptor，发现 BOS 里的 Device Capability 长度字段写的是 0x0A（10 字节），但实际 VDO 只有 8 字节。Host 解析时连续读了两次，数据错位，导致 PD 协商失败。
1.5 为什么 PD 调试要从 Descriptor 入手？
很多人觉得调试 PD，应该先抓 PD 层的时序，看 SOP、看 GoodCRC。这个思路没错，但不够完整。我个人的调试顺序是：
- 先看 Descriptor： 用工具（比如 USBTreeView、USB Device Viewer）读一遍 Descriptor 全量数据。
- 再抓 PD 日志： 用逻辑分析仪或 PD 分析仪抓取现场通信数据。
- 对照验证： 如果 PD 协商失败，90% 的原因可以在 Descriptor 中找到线索。
小技巧： 我习惯在项目初期，先把 Descriptor 固定成“标准模板”，用 Bus Hound 或 usbview 工具模拟一遍枚举。如果枚举通过，再根据 PD 需求修改 BOS 和 VDO。这样可以把验证周期缩短 30% 以上。
1.6 本章小结
USB Descriptor 不是软件工程师的专属工具，它和硬件调试、PD 协议有着深刻的联系。我自己调试过的项目中，Descriptor 字段写错导致的 PD 协商失败，占比至少在 40% 以上。
所以我的建议是：在拿到一个新设备的 PD 调试任务时，别急着上示波器抓波形。先把它的 Descriptor 完整读一遍，尤其是 BOS 和 VDO。你会发现很多问题，根本不需要动烙铁。
后面我们会逐一深入每个 Descriptor 的具体字段，以及它们在 PD 协商每个阶段发挥的作用。嗯，路还长，但基础扎实了，调试起来才能有的放矢。