TYPECPD升压协议全解析.doc

TYPE-C PD升压协议全解析
PD是Power Delivery的简称，代表着TYPE-C电力传输的一个通讯协议。
一个简朴的TYPE-C PD使用环境，需要下面几个设备构成： HOST、DEVICE、CABLE（即：主机，机，EMARKER）
PD的协议书重要的内容集中在：
Ÿ PD协议的BMC编码规则；
Ÿ PD协议的4B5B解码；
Ÿ PD协议的通信流程；
Ÿ PD协议的通信指令结构；
Ÿ PD协议的通信内容解析；
㈠
PD协议独立与USB协议之外，但由于TYPE-C口的兼容特性，可以让PD协议、QC协议、MTK协议、FCP协议等快冲协议熔于一炉。
PD的物理层由发射模块和接受模块组成，由于CC是单线协议，所以所有通信都是半双工的。
BMC编码规则是曼切斯特编码的一个版本，按照脉宽来设定的0和1。

可以从上图看出，01的编码并不以电平的变化为依据，而是按照脉宽来决定。
BMC的最大频率达330KHz，单指令长度在1ms内。
㈡
通过逻辑分析仪对波形的读取，我们可以看到未经BMC解码的原码

通过BMC从左到右按照脉宽解码后，我们可以得到一系列01的无序组合。
通过对01组合的观测，可以看到从左开始有64对01的前导码，来作为数据的等待和除干扰。64对前导码后，才是需要关注的数据内容。
通过BMC解码后，并去除前导码的数据，也并不是最终可以解析的数据。PD通信协议在这里增长了一个软编码，称为4B5B编码。即接受到的数据每5个二进制数据，需要通过一个4B5B编码表还原成对的的PD通信数据。
看到这里，都可以想到无线电的加密工作了，但是PD官方资料给出的解释是4B5B是为了减少接受器的设计复杂度并且允许更加多样化的接受器设计。
4B5B的解码表如下：

根据图二我们可以做一个4B5B的解码例子：
取出图二中引导码后，我们可以得到的数据：00011 00011 00011 10001 10010，通过上述4B5B表格进行解码后我们得到最终的数据为：SYNC1- SYNC1-SYNC1-SYNC2-1。
看到这里也许你有疑问，00011在表格中不是Reserved吗？是的，没错，4B5B尚有个编码规则，就是从左到右记录数据时，需要将读取的数据倒过来编译，即00011要倒成11000。
由于PD通信的流程复杂，且BMC解码后的数据往往长达上百位，人工编解码耗时耗力且容易犯错，所以需要使用一些自制的电脑软件来进行辅助解码，于是才有了下面的自制解码软件。

该软件就涉及了4B5B的解码，和数据内容的解析，可以快速的将BMC解码的数据内容转换成功能定义。
㈢
PD协议内容繁多，重要涉及以下流程：
·Power Negotiation 电压协商流程（电压升降压）
·Gotomin Operation
·Soft Reset 软件复位流程
·Hard Reset 硬件复位流程
·Cable Reset
·Power Role Swap
·Fast Role Swap
·Data Role Swap
·VCONN Swap
·Addition Capability and Status
·Security 密钥流程
·Firmware Update 固件升级流程
·Structured VDM 厂商自定义结构流程
·BIST PD协议时序测试流程
今天我们就根据Power Negotiation讲解PD电压升降的流程结构。
Power Negotiation流程发生在Source与Sink之间，在这里Source
可以是适配器，可以是车充，也可以是移动电源。Sink可以是任何支持Type-c PD的受电端。
Power Negotiation的协议流程涉及以下PD指令：
·Source send CAPABILITY 供电能力指令（包含内容：具有哪几种电压值和电流值）
·Sink send REQUEST 需电请求指令（包含内容：选取哪种电压和电流值）
·Source send ACCEPT 批准需电请求指令（包含内容：通过对比需电在自己的供电范围内）
·Source send PS_RDY 完毕需求指令 （包含内容：已经成功进行能电压改变）
·GOODCRC 指令接受通过指令
在实际应用中这些指令是怎么操作的呢，接下来我来具体述说：首选Source
端工作在TYPE-C的CC模式5V3A检测模式下，一旦检测到有SINK受电端接入，便开始输出5V给SINK端。
而这时在CC线上，Source开始不间断发送Source send CAPABILITY指令，SINK端接受到Source send CAPABILITY指令后，判断PD通信数据符合协议规定，便回复GOODCRC表达已经成功接受到数据，接着SINK会根据Source端可以提供的电压进行选择，SINK选择好合适的电压电流便对SOURCE进行供电请求，于是SINK发出Sink send REQUEST进行需电请求指令。
Source接受到Sink send REQUEST后，会给SINK回复GOODCRC，然后对Sink send REQUEST指令请求的电压进行校对，假如符合Source的供电能力，Source便对SINK发Source send ACCEPT指令，表白批准SINK的端电压请求。SINK接受到Source发送的ACCEPT指令后，回复GOODCRC。Source接受到SINK发出的GOODCRC后，便开始进行电压调节，电压调节成功后，便发出Source send PS_RDY表达已经调整电压成功，SINK收到后，便回复GOODCRC表达接受指令成功。
以上就是一个完整的升压指令流程。
㈣
PD的通信指令（就升压来说）有两种方式一种方式是控制包，而另一种是带数据包。
指令包格式如下：

一个完整包结构涉及引导码，SOP*使用场景码，Message Header功能码，Byte0-n数据码和CRC校验码，EOP结束码。
假如Byte数据码没有，说明指令仅仅作为控制指令使用，没有数据内容，所以叫做控制包。有数据内容的叫做数据包，通常数据包里携带了要变化的电压值和电流值等信息。
② 引导码：BMC解码后可以看到由64对01组成，重要为了进行接受缓冲。
②SOP*码：BMC解码后由20位的二进制数组成，通过4B5B解码后我们可以看到SOP由Sync1和Sync2的解码值构成。表白该指令是应用在Source与SINK之间。此处尚有SOP’、SOP’的场景码，表白是Source与E-marker之间的场景指令。
③Message Header功能码：BMC解码后由20位的二进制数组成，通过 4B5B
解码后为16位二进制数据构成。
Message Header通常涉及：数据包还是控制包说明，是由SINK还是SOURCE发出的指令，PD的协议版本，假如是数据包还包含了有多少个数据包的信息。
具体表格说明如下：

其中，低四位二进制码比较重要，代表的是该PD指令的名字，比如说升压中用到的Source send CAPABILITY就是又这四位来定义的。
其它指令的定义表如下：

在指令包的结构中，过了Message Header向右就是数据区域，通过4B5B的转换后，SOP是16个二进制位，Message Header也是16个二进制位，而数据区域，每个独立的数据块涉及了32个二进制位。所以Byte0（32位）Byte1（32位）......那么新的问题又来了，一条完整的指令包到底怎么判断包含了多少的数据块呢，这个时候就需要由Message Header来进行判断了。Message Header的12到14位表达1到7个数字，代表的就是指令包的数据数量，所以我们可以认为指令包的最大数据数为7。数据模块一般应用在Source send CAPABILITY，Sink send REQUEST等这样需要带电压电流的PD指令中。
数据模块右边就是一个32位的数据校验区域也称作CRC校验。CRC校验是PD通信协议中独特的一套校验方式，为了保持数据的完整与纠错，整个PD指令任何一个位变动，都会导致CRC改变。
通过了引导码、SOP码、MessageHeader、data码、CRC码后，接下来就是EOP码即结束码，在4B5B中我们可以看到接受到01101的BMC编码，即代表PD指令包所有接受完毕。
㈤
下面我们就实际做一次PD协议分析：
一方面准备好待测试的PD适配器、PD数据线（两头都是TYPE-C的那种）、PD测试架、逻辑分析仪。
然后将插拔过程中PD的数据流程通过逻辑分析仪读取出来如下：

一方面我们要做的就是PD指令的BMC解码，将脉冲长短变化成二进制数据，然后通过协议分析软件进行代码解析，为了更好的讲解，我们先人工分析一条指令。

引导码由64位二进制的01组成，这一段可以直接略过。

SOP*码从左到右BMC解码后等于：00011 00011 00011 10001
根据图三进行4B5B解码我们可以得到：SYNC1-SYNC1-SYNC1-SYNC2
于是我们可以知道，该指令属于SOURCE与SINK之间的指令。
我们接着往下分析：

Message Header码从左到右BMC解码后等于：10010 01110 10010 00101。通过4B5B解码后为：0001 0110 0001 0010。
15到0位为：0010 0001 0110 0001 根据图六可以得到以下信息：
  从15，14，13，12位可以得到此PD指令涉及2个数据块。
  从11，10， 9位可以知道此PD指令正在进行第一个回合。（PD指令+GOODCRC指令为一个回合）
  从8位可以得知此PD指令由SOURCE发出。
  从7，6位得知指令遵循的是PD2.0规则。
  从5得知发指令的设备角色为DFP。
  从4，3，2，1，0得到00001并查阅图七得到该指令名：Message Header指令，为电压协商协议的发起指令。
数据指令过长过程不再详叙，用协议软件可以分析得到：

接下来我们用协议软件分析，速度会快很多，可以迅速掌握这个流程功能和异常：

此指令为上条Message Header的回复指令。
接着下条指令为：

此为SINK端发出的Sink send REQUEST指令，我们可以得到相关信息，已经SINK请求的电压等级。
SOURCE端的回复指令：

从该指令信息中，我们可以知道该信息由SOURCE发出，用来回复SINK端发出的电压请求。
接着SOURCE端收到指令后，又发出的指令：

该指令信息为SOURCE发出的ACCEPT指令，由上述流程的介绍可以知道，该指令表白SOURCE端批准了SINK的电压升压请求，并开始做好升压的准备。
接下来SINK端发的GOODCRC，如下：

该指令为SOURCE发的第二条指令，所以SINK回复的GOODCRC中的MSGID这里开始计数到001；
与此同时，SOURCE端的硬件已经进入升压模式，由于升压要一定期间，所以PD通信会有90ms多的延时，才迎来了第三条SOURCE指令，假如流程没有错的话就是 PS_RDY指令：用PD协议分析软件的分析如下：

指令流程进行到这里，说明SOURCE端已经成功将电压升压到SINK端请求的电压。接下来的SINK端的GOODCRC就不累赘了。
以上叙述就是一个完整的电压升压流程PD通信的速率300KHz，且通信时的电压在1V上下，所以在实际的软硬件设计中，都要针对上述特性做一些针对性的调整。
目前开发的SINK端PD测试架，与配合AC-DC做的PD协议芯片都是以上述理论为蓝本做的相关应用。
两款样机的硬件设计请见PD硬件，软件设计篇。