第3章：描述符定位的概念与重要性归纳总结
说实话，我刚接触USB PD的时候，对“描述符”这三个字完全没感觉。
不就是一堆结构体吗？用工具读出来，看看VDO、PDO、RDO这些字段，不就行了？
直到有一次，我连着一台扩展坞，怎么都协商不到20V。抓了一整天波形，眼睛都快看花了，才发现问题出在——我看错了描述符的位置。
嗯，从那以后我才真正理解：描述符定位，是PD调试的第一块基石。
3.1 什么是描述符定位
简单说，描述符就是设备用来告诉对方“我能干什么”的一套数据包。它们藏在每个端口的Device Capabilities里，按固定格式排列。
定位嘛，就是在海量的二进制数据中，找到你关心的那一小段。
- Source Capabilities：电源能输出哪些电压电流组合（PDO列表）
- Sink Capabilities：设备能接受哪些电压电流组合（RDO列表）
- VDO（Vendor Defined Object）：厂商自定义的能力声明，比如Alternate Mode支持什么协议
- ID Header / Cert Stat：芯片身份、证书状态等辅助信息
你想想看，这些描述符如果位置读错了，后面的分析全是废的。
我个人的小习惯：每次抓新设备的PD log，第一步不是看电压值，而是先把描述符的偏移量标出来。就像查地图先找经纬度一样。
3.2 为什么我们都得重视它
曾经有一个项目，我负责调试一款双Type-C口的充电宝。两个口都能输出，但手机插上去老是只有5V。
我反复检查Source Capabilities的PDO列表，电压、电流都写对了。但就是跑不起来。
后来我同事点了一句：“你看看第二口描述符的起始地址是不是偏了？”
一查，哎，芯片配置里把两个口的描述符地址写反了。第一个口的PDO被当成第二个口的去解析，当然乱套。
从那以后，我每次做PTR（Pre-Test Report）之前，都会先跑一遍描述符定位检查。
| 出问题的地方 | 典型表现 | 根源 |
|---|---|---|
| PDO电压/电流数值错误 | 协商不到目标电压 | 描述符基址偏移算错 |
| VDO内容无法识别 | Alternate Mode无法进入 | VDO索引对应错误 |
| RDO一直返回拒绝 | Source不响应Sink的请求 | RDO格式解析偏差 |
| 多端口设备行为错乱 | 插口A却触发了插口B的策略 | 描述符地址映射混乱 |
你看，这些问题的根源，多数都能追溯到描述符的“位置”没找对。
3.3 描述符定位的核心三要素
我一般把描述符定位拆成三个维度，方便自己排查时对号入座。
- 偏移量（Offset）：描述符在Device Capabilities中的起始字节。比如第一个PDO从Byte 0开始，第二个从Byte 4开始。记错了，一个字节的偏差，整个PDO就读歪了。
- 长度（Length）：每个描述符占多少字节。PDO一般是4字节，VDO可以是0~24字节。长度不对，后面的描述符全跟着挪位。
- 编号（Index）：同一个描述符类型可能有多个实例。比如Source可以发1~7个PDO。编号错位，你读到的可能是隔壁邻居的数据。
在实践中，我最常用的方法就是“二进制对照法”：把抓到的原始字节流按4字节一行对齐，然后手动标出每个PDO的偏移。虽然有点笨，但几乎不会漏掉定位错误。尤其是遇到那些芯片供应商改了寄存器映射但文档没更新的情况，这招特管用。
3.4 一张图理清描述符定位的结构
3.5 归纳总结：定位能力决定了调试效率
说一千道一万，描述符定位这个概念，最终要落到一个能力上：你能否在10秒内快速锁定问题描述符的位置。
我推荐的做法： 每次拿到一个新的PD抓包文件，先花30秒时间，用文本或16进制编辑器把整个Device Capabilities按4字节一行排好。然后对照PD规范的Table，标出PDO开始位置、RDO位置、VDO开始位置。 这步做完了，后续所有分析都会顺畅很多。
我曾经吃过的一个亏：有一次我手上的PD分析仪显示Source Capabilities包只有12字节，我默认认为前4字节是VDO，后面8字节是两个PDO。结果设备死活不协商。后来才发现，芯片厂商的实现在VDO之后加了一个空填充（padding），导致PDO的偏移多了4字节。嗯，从那以后我养成了“先校验总长度，再对齐每段描述符”的习惯。
描述符定位不是玄学，是基本功。打好这个基础，后面所有关于PDO电压计算、VDO解析、协议状态机分析，才能站得稳。
我个人习惯把这章的内容做成一个口袋卡片，放桌上。每次定位不清的时候，瞄一眼这张图，思路马上清晰。