本文使用Totalphase出品的PD Analyzer协议分析仪，以Razor手机通过USB-C to USB-C线连接LG显示器为例，分析通讯过程。
TotalPhase Power Delivery Analyzer
一、背景知识
在开始之前，我们要先看一下背景知识。
以下内容参考官方PD文档的 物理层Physical Layer 部分。
USB PD物理层包括一个发送端一个接收端，它们通过一根CC线连接。因此它是半双工的。
发送端的功能：
- 从协议层接收数据包packet data
- 计算出CRC并追加在包后
- 对packet data和CRC进行编码，得到payload
- 通过CC线、使用BMC编码、把数据包(包括Preamble, sop*, payload, CRC, EOP)发送出去
接收端的功能：
- 收到Preamble时，获取到时钟clock并锁定
- 检测包的开始标志SOP*
- 解码收到的数据（包括CRC）
- 检测包的结束标志EOP，验证CRC
- 如果CRC验证有效，把数据包传给协议层
- 如果CRC验证无效，丢弃数据包。
1.1 包格式USB Power Delivery Packet Format
先看一下官方文档对于包格式的定义。
Packet Format
所有的Message必须包括如图中的几部分，其中数据部分视情况可有可无。
Message的产生，
要么1）来源于协议层、被传送到物理层（对应发送的情况），
要么2）被物理层接收到，然后传送到协议层（对应接收的情况）。
USB PD Message Format
USB Power Delivery Packet的组成
- Preamble前导码
- SOP* 的长度为20 bits，在4b5b反编码后是16 bits。
- Message Header
- Packet Data (Byte 0, Byte 1, ... Byte n-1, Byte n)
- CRC
- EOP (End of Packet)
1.1.1 Preamble前导码
Preamble前导码：由32对01组成（由0开始由1结束），用来锁定接收端。
注意：
。而
1.1.2 SOP*
SOP* (Start of Packet)标志着包的起始。
SOP* 是个通配符，代表着以下几种可能。
image.png
SOP的定义为Sync-1, Sync-1, Sync-1, Sync-2. （按K-code 1到4的顺序）
按照4b5b编码表，它的二进制表示为：00011, 00011, 00011 10001
常见的SOP*的定义如下：
| SOP* | 定义(K-code 1,K-code 2,K-code 3,K-code 4) | 4b5b编码后的二进制表示 | 用途 |
|---|---|---|---|
| SOP | Sync-1, Sync-1, Sync-1, Sync-2 | 00011 00011 00011 10001 | |
| SOP' | Sync-1, Sync-1, Sync-3, Sync-3 | 00011 00011 01100 01100 | |
| SOP'' | Sync-1, Sync-3, Sync-1, Sync-3 | 00011 01100 00011 01100 | |
| SOP'_Debug | Sync-1, RST-2, RST-2, Sync-3 | 00011 10011 10011 01100 | |
| SOP''_Debug | Sync-1, RST-2, Sync-3, Sync-2 | 00011 10011 01100 10001 | 目前未定义 |
1.1.3 Message Header
每个Message必须要以Message Header开头。
Message Header中包含了Message的基本信息，以及PD端口的能力
USB PD Message Format
说明：
1）bit 15: 对所有SOP*包有效。
> 当Message类型为Control Message或Data Message时，bit 15须设为0；此时紧接着的3 bits(bit 14, 13, 12)代表Message Header后面跟着的32-bit Data Object的个数。
> 当Message类型为Extended Message时，bit 15须设为1。此时在Message Header后面必须紧跟一个16-bit的Extended Message Header。含义如下所示。详情参照官方文档103页。
2）bit 14, 13, 12：表明Data Object的个数，对所有SOP*包有效。
当它为0时，代表此Message为Control Message。
当它不为0时，代表此Message为Data Message。
- bit 11, 10, 9: 表明Message ID。对所有SOP*包有效。
当软重启或硬重启时，MessageID被重置为0。每次Message被成功收到后（以接收方发出一个GoodCRC Message为标志），MessageID加一。- bit 8:
> 当SOP=SOP时，bit 8代表Port Power Role。
> 当SOP=SOP'或SOP''时，bit 8代表Cable Plug。当bit 8代表
Cable Plug时，它表明此Message的来源：
> 如果来源于DFP或UFP，bit 8=0b
> 如果来源于Cable Plug或VPD(Vconn Power Device)，bit 8=1b
- bit 7, 6: Spec Revision。可能值如下。
> 00b: Rev 1.0
> 01b: Rev 2.0
> 10b: Rev 3.0
> 11b: Reserved;不应当使用此值
更多详情请参考官方文档101页。- bit 5: 当包类型为SOP时，表明Port的当前data role；否则，设为0(Reserved)。
Data Role的可选值有2个：
> 0b 代表UFP
> 1b 代表DFP
在硬重启或端口attach时USB Type-C Port的Port Data Role会重置到默认值，根据CC线上电阻的阻值和接法（上拉还是下拉），此默认值不同：
> 当检测到Rd时(UFP)，默认值为0b
> 当检测到Rp时(DFP)，默认值为1b
Termination Resistors Required for USB Type-C Connector
题外话：Rd为固定值5.1kΩ。Rp的值，根据USB-C端口的电流输出能力、以及上拉到电平的不同而不同，数值如下表。USB-C线中的Ra的值在800Ω-1.2 kΩ。上图和下图来自Cypress。
当端口不具有USB通讯能力时，在连接的时候Source端口必须进入DFP角色而Sink端口进入UFP角色。
bit 4, 3, 2, 1, 0: 表示Message类型。
首先要先检查bit 14, 13, 12（Number of Data Objects）来判断此Message是Control Message还是Data Message，然后再参照下面的2个表格来得到Message类型。
不同类型的Message包有不同的格式：
Control Message的包格式
Data Message的包格式
Extended Message Header的包格式
1.1.4 Packet Data
1.1.5 CRC
1.1.6 EOP (End of Packet)
1.2 编码
除了Preamble之外，所有的通讯都必须经过4b5b编码。编码的原因，官方是这么说的：
This encoding makes receiver design less complicated and allows for more variations in the receiver design.
发送端将4位数据编码成5位，传送到接收端后，由接收端反编码回4位。
除了编码的功能，4b5b还提供了特殊字符。
4b5b的编码表如下：
4b5b编码表
1.3 Ordered Sets
这个20 bits的SOP*称为Ordered Sets，它由4个5 bits的符号组成，从低位开始，分别称为K-code 1, K-code 2, K-code 3, K-code 4。
image.png
除了SOP*外，Ordered Sets还有其它几种可能值。USB Power Delivery用到的Ordered Sets如下：
image.png
容错机制：在实际的传输中，接收端可能无法收到全部的4个K-code。只有在某些情况下，接收端才认为接收到的数据是有效的。这些情况列举如下：
image.png
1.4 数据传输顺序
4 bits数据在经过4b5b编码后会增加一个bit变成5 bits。所以三种常见数据类型在编码前后的字节变化如下表所示。
image.png
最低位先被传输，即LSB First。
Transmit Order
二、数据采集
数据采集的过程很简单：
- microUSB线连接PD Analyzer协议分析仪到电脑，打开DataCenter软件，设置好后，开始捕获。
-
PD协议分析仪连接Razor手机，然后通过USB-C to USB-C线连接LG显示器 - 捕获完成后，保存数据。
Screenshot
三、数据分析
下面是通讯过程分析。
3.1 Soft_Reset
连接建立后，先进行软重启。
此时MessageID被重置为0（无论是软重启还是硬重启）。
3.1.1 Preamble前导码 (64 bits)
首先看到的是64 Bits前导码(Preamble)，即01010101....01010101(01共重复32次，或者说0101重复16次)
Block View
image.png
每次数据通讯的开始，都会看到这个前导码：
image.png
3.1.2 Ordered Set (20 bits)
前导码后面是20 bits的Ordered Set，此处为：
00011 00011 01100 01100
因为我们接收到的是LSB first，所以要把bits的顺序方向反一下：
11000 11000 00110 00110
image.png
查询4b5b编码表，可以得到：
Sync-1, Sync-1, Sync-3, Sync-3
即，SOP'。Data Center已经帮我们解释出来了。
image.png
3.1.3 Message Header (20 bits)
接下来的20 bits是Message Header。
11011 01010 01111 01111
因为发送时是LSB First，所以要把顺序反一下。得到：
11110 11110 01010 11011
按4b5b反编码后：
0000 0000 0100 1101 (16进制为004D)
此即为Message Header。
Message Header的含义解释如下表。
| bit(s) | 当前值 | 含义 |
|---|---|---|
| 15 | 0 | 此Message类型为Control Message或Data Message |
| 14-12 | 000 | 表明Data Object的个数为0，说明此Message为Control Message |
| 11-9 | 000 | Message ID。因为刚刚发生了软重启，所以MessageID被重置为了0 |
| 8 | 0 | 因为这是一个SOP'包，所以此bit代表Cable Plug。0表明此Message来源于DFP或UFP |
| 7-6 | 01 | Spec Revision v2.0 |
| 5 | 0 | 此bit在包类型不是SOP时没有意义 |
| 4-0 | 01101 | 表示Message类型，查Table6-5得知是Soft_Reset。 |
对比一下Data Center解析出来的信息，一致。
3.1.4 Data Object 无
3.1.5 CRC
传输开始前，要完成CRC编码。
编译规则如下(官方文档75页)：
- CRC-32多项式为：04C1 1DB7h
- 初始值为：FFFF FFFFh
- CRC-32的计算要对所有payload进行，但不包括packet framing symbols，比如说Preamble, SOP*, EOP等。
- 计算从第0字节的第0位开始，到最后一个字节的第7位结束。
- CRC-32的remainder必须补齐(complemented)。
- CRC-32的residual必须为 C704 DD7Bh。
Table 5-10: CRC-32 Mapping (From USB.org官方文档)
| CRC32 | Result bit position in CRC-32 field |
|---|---|
| 0 | 31 |
| 1 | 30 |
| 2 | 29 |
| 3 | 28 |
| ... | ... |
| 28 | 3 |
| 29 | 2 |
| 30 | 1 |
| 31 | 0 |
3.1.6 EOP（End Of Packet）
包的结束标志。从Table5-1中可以看到，它的5b值为01101。
3.2 GoodCRC
| 读到的数据 | bits数 | 名称 | 意义 |
|---|---|---|---|
| 0101...0101 | 64 | Preamble前导码 | 时钟对齐 |
| 00011 00011 01100 01100 | 20 | Ordered Sets | SOP' |
| 10010 01010 10010 01111 | 20 | Message Header | |
| 11011 00101 01 | 12 | ？ | 补齐32bits？ |
把Message Header调整好顺序后：
11110 01001 01010 01001
然后4b5b反编码后：
0000 0001 0100 0001
Message Header意义如下：
| bit(s) | 当前值 | 含义 |
|---|---|---|
| 15 | 0 | 此Message类型为Control Message或Data Message |
| 14-12 | 000 | 表明Data Object的个数为0，说明此Message为Control Message |
| 11-9 | 000 | Message ID。同上一条Message的Message ID，为0 |
| 8 | 1 | 因为这是一个SOP'包，所以此bit代表Cable Plug。1表明此Message来源于Cable Plug |
| 7-6 | 01 | Spec Revision v2.0 |
| 5 | 0 | 此bit在包类型不是SOP时没有意义 |
| 4-0 | 00001 | 表示Message类型，查Table6-5得知是GoodCRC。 |
对比Data Center解析出来的信息，一致。
网友评论