1 USB PD协议详解-德赢Vwin官网 网

USB PD协议详解

电子说

1.3w人已加入

描述

0x00 USB PD协议背景知识

USB PD(Power Deliver)协议是USB IF协会制定的USB充电标准与技术,是目前主流的快充协议之一,其最大供电能力可达100W,被应用在各种设备的电源上。USB PD协议利用USB Type-C接口的CC(Configuration channel)引脚作为数据传输通道来协商充电的电压、电流和功率传输方向,在介绍USB PD协议的具体内容之前,先简单介绍一下其依赖的USB Type-C接口。

CRC效验

如上图所示,Type-C接口可以完全替代Type-A、Type-B、Micro AB等各种USB接口,实现数据传输、电力传输。USB PD协议就是基于Type-C接口的强大功能实现的。Type-C接口的引脚示意图如下所示,VBUS为总线电源,D+、D-为USB2.0的差分信号线,TX+、TX-、RX+、RX-为SuperSpeed差分信号,SBU(Sideband Use)为旁路使用,CC为配置通道。Type-C接口最大功率传输可达100W(20V/5A),最大数据传输速率为10Gbps。可以看到,在公头上只有一个CC引脚,母头上的CC引脚是对称的,所以也可以利用CC引脚判断正反插。

CRC效验

USB PD协议的工作原理是利用Type-C接口的CC线作为数据线来协商电压、电流以及供电方向,整个通信过程需要按照特定的数据包格式,并且存在相互认证的过程。下面先介绍一些USB PD中常见的名词,这些名词在后面也会用到。

  • Source:通常指电源提供端,如电源适配器。
  • Sink:通常指电源消耗端,如手机、平板。
  • E-Marker(electronic marker):电子标记,一般存在于Type-c to Type-c的线缆中。
  • CC(Configuration Channel) :配置通道,用于识别、控制等。
  • BMC(Biphase Mark Coding):双相位标识编码,通过CC通信。
  • DFP(Downstream Facing Port):下行端口,即为HOST或者HU B下行端口。
  • UFP(Upstream Facing Port):上行端口,即为Device或者HUB的上行端口。
  • DRD (Dual-Role Data):能作为DFP/UFP。
  • DRP (Dual-Role Power):能做为Sink/Sour ce。
  • SOP(Start of Packet Sequences):所有的PD传输流程,都是以SOP开始,SOP*代表SOP,SOP’,SOP''。
  • EOP (End of Packet):数据包结束标志。

0x01 USB PD协议的数据格式

USB PD协议通过特定格式的数据包进行通信,数据包的格式如下所示。

CRC效验

一个完整的USB PD数据包由前导码(Preamble),使用场景码(SOP*),功能码(MessageHeader),数据码(Byte0-n)、校验码(CRC)以及结束码(EOP)组成,如果数据部分为空,说明数据包仅作为控制指令使用,称为控制消息。有数据内容的称为数据消息,通常数据消息里包含了要变化的电压值和电流值等信息。整个USB PD数据包中,除了前导码不需要进行4b5b编码外,数据包的其他部分均需要进行4b5b编码,指定数据经过4b5b编码后,数据包中所有数据都需要使用BMC编码之后才能通过CC发送。4b5b编码和BMC编码会在下一章节详细介绍。

前导码(Preamble)

前导码(Preamble)是为了锁定接收端,预示发送端将要有数据到达,前导码由64位交替的‘0’和‘1’组成,以'0'开始,以'1'结束。

使用场景码(SOP*)

所有的USB PD传输流程,都是以SOP开始,SOP代表SOP,SOP',SOP''。不同的使用场景会用到不同SOP,每一个SOP也由不同的特殊编码组成。如SOP是由3个Sync-1和1个Sync-2组成,对应的5b编码可以在4b5b编码表中查到。

CRC效验

数据包使用SOP作为开头,说明该数据包是在Source与Sink之间进行的。

SOP'由2个Sync-1和2个Sync-3组成,其顺序如下图。

CRC效验

SOP''也是由2个Sync-1和2个Sync-3组成,但是其顺序与SOP'不同。

CRC效验

数据包使用SOP'或SOP'',则说明是Source与E-Marker之间的通信过程,不同的是,SOP'体现的是Source与线材近端E-Marker的通信,SOP''体现的是Source与线材远端E-Marker的通信。

功能码(Message Header)

功能码长度16-bits,通常包含数据包类型、端口角色(UFP/DFP)、PD协议版本等信息,功能码的组成如下图所示。

CRC效验

从列表中可以看出,不同的功能码需要特定的SOP*,这个在之前也有提到,下面介绍一些常用的功能码。

Extended

Extended是用来表示该数据包是否包含外部指令的功能码,该位置1,表示数据包中存在外部指令,反之则没有。如果数据包中包含外部指令,指令内容会跟在功能码后面进行传输。USB PD协议的外部指令使用的比较少,在这里就不做详细的介绍了。

Number of Data Objects

当Extended置0时,Number of Data Objects才可以使用,该功能码有3-bits,用来表示功能码后跟的数据的位数,如果Number of Data Objects置0,则表示功能码后没有数据,该数据包为控制消息。如果该功能码置1,则表示该数据包为数据消息。

Port Power Role & Port Data Role

这两个功能码都是表示端口的电源角色(Source/Sink)和数据角色(DFP/UFP),该位置1时表示Source/DFP,该位置0表示Sink/UFP。

Message Type

Message Type有5-bits,是功能码中比较重要的位,需要和Number of Data Objects 结合使用,前面提到Number of Data Objects决定了数据包的消息类型,Message Type 则表示具体的指令类型。当Number of Data Objects置0, Message Type则可以表示以下控制指令。例如当接收器成功接收数据包并CRC校验正确后,会向发送端发送带有GoodCRC和Message ID的数据包,来表示通信成功。

CRC效验

当Number of Data Objects置1时,Data Message Types可表示以下指令,例如Source会在通信过程中向Sink发送Source_Capabilitties来表示供电能力,Sink可以从供电能力列表中进行选择并通过Request指令发送给Source端。

CRC效验

数据码(Byte0-n)

数据码只有在数据包类型为数据消息时才会使用,具体的数据内容需要根据指令的内容改变,例如在使用Source_Capabiliities消息指令时,数据码就会存放Source的供电能力。数据码同样需要使用4b5b进行编码。

校验码(CRC)

功能码和数据码都需要由32bits的CRC校验进行保护,校验码的生成机制比较繁琐,一般都会使用查表的方式实现,在这里也不做详细的介绍了,感兴趣的小伙伴可以参考USB IF协会的官方文档。

结束码(EOP)

结束码表示整个数据包的结束,在4b5b编码表中可以找到对应的5b编码,为01101。

0x02 USB PD协议的编码方式

4B5B编码

在USB PD协议的数据包中,除了前导码(Preamble)之外,其他部分均需要使用4b5b编码,官方的说法是为了降低接收端设计的复杂度,提高接收端设计的自由度。4b5b编码的原理是建立一个4b5b编码表,将4-bits的数据与5-bits的数据进行对应,发送端根据编码表对4-bits数据进行编码,接收端根据编码表对5-bits数据进行解码,编码表的具体内容如下图所示。

CRC效验

从图中可以看出,除了基本的hex数据外,还定义了一些特定的编码,如Sync-1、RST-1等,这些特定的编码会组成SOP*,在介绍USB PD协议数据格式时也有提到。另外,编码表中还预留了多个未定义的5b编码,可以作为的扩展指令使用。

BMC编码

USB PD协议的数据包中,所有的数据都需要使用BMC进行编码,BMC编码属于物理层的操作,经过编码之后的数据通过CC线进行传送。

CRC效验

上图为BMC编码的示例,BMC编码规则是曼切斯特编码的一个版本,按照脉宽来设定的0和1,从示例中可以看到,在一个周期里有高低电平变化为1,否则为0。

USB PD协议编解码流程

以上详细介绍了USB PD协议数据包的格式和各个部分的功能,那么对于一个完整的数据包,发送端发送的流程是什么,接收端接收到数据之后会进行哪些处理呢。

CRC效验

上图为一个完整的数据包发送和接收的流程图,可以看到,在发送数据时,需要将经过CRC校验后的数据使用4b5b编码,再使用BMC编码才可以通过CC发送。在接收数据时,首先进行BMC解码,然后需要确定SOP的位置,因为SOP后的数据才是真正的有用的数据,再进行5b4b的解码,校验CRC。

介绍完理论,来看一下在实际的数据包。下面是使用逻辑分析仪抓取的USB PD协议通信数据包,使用上面介绍到的内容对这个数据包进行解析。

CRC效验

首先,BMC解码,根据BMC编码规则,识别出'0'和'1',已经标注在图中。SOP识别,标注出的前20 bits为00011 00011 00011 10001,我们可以将这些数据理解为4组经过4b5b编码的数据,由于在传输数据时采用大端模式,所以需要将数据的高低位交换,转换之后为11000(Sync-1) 11000(Sync-1) 11000(Sync-1) 10001(Sync-2),也就是SOP(Sync-1、Sync-1、Sync-1、Sync-2)。同样的,SOP后的数据也需要先高低位交换,识别结果为Source_Capabilities,说明该消息是用来表明Source的供电能力的,那么数据包中也会包含数据码,分析的方法跟前面也是一样的。

在日常的工作中,其实并不需要手工去分析大量的USB PD的消息类型,目前大部分逻辑分析仪都可以对USB PD协议进行解析,另外也可以借助CY4500 EZ-PD™协议分析仪对USB PD通信逻辑进行分析,只有部分逻辑分析仪无法识别的内容,才需要我们根据协议内容去进行分析,这些内容大部分是USB PD芯片厂商定义的调试消息类型。

以上详细介绍了单个USB PD数据包的构成,以及如何去识别数据包的内容,DFP和UFP通过数据包进行通信,就是USB PD协议认证协商的过程。

0x03 USB PD协议认证协商

我们知道,不同的设备需要不同的充电电压、电流,手机需要9V/2A,平板需要15V/2A,电脑需要20V/3.25A,那么电源是如何实现根据设备需求提供定制化输出的呢?

支持USB PD协议的设备,在与电源连接时,会进行认证和协商,协商内容包括电源可提供的充电能力,设备支持的充电功率等。

CRC效验

上图为USB PD认证协商的流程图。首先DFP向UFP发送Source Capabilities 来表明其供电能力,UFP接收到该数据包校验无误后会向DFP发送GoodCRC,表明接收成功,随后UFP会从DFP的Capabilities中选择合适功率并使用Request消息发送给DFP,同样DFP也会对数据包校验并返回GoodCRC。DFP在收到UFP的Request之后,会判断能否满足该Request,如果可以则发送Accept,同时DFP会调整内部电源,准备向UFP供电,准备完成之后会向UFP发送PS_Ready消息并将电压、电流转换成UFP请求的值,待UFP回复GoodCRC,整个协商过程完成,电源与设备建立起快充关系。

CRC效验

上图是使用CY4500 EZ-PD™协议分析仪对协商过程进行监控得到的数据,从数据中可以看出,在DFP发送PS_Ready消息之前,VBUS的电压为5V,电流几乎为0,在DFP发送PS_Ready消息的同时,VBUS电压升为20V,开始对设备进行快充。

0x04 USB PD协议安全性分析

前面详细介绍了USB PD协议的数据格式、协商认证过程,了解了其工作原理,USB PD协议的具体实现需要使用USB PD芯片,USB PD协议本身也是公开的,数据包中包含CRC校验,并使用4b5b编码和BMC编码,可以说协议在设计的时候就把安全考虑进去,但是各个厂商的USB PD协议芯片的安全性可以说是参差不齐了。USB PD协议芯片一般包括物理层、协议层和策略层,物理层包括一些通用寄存器和PD专用寄存器,还有BMC编解码的功能等,协议层就会包含SOP*的识别、协议的实现等内容,策略层则包括一些上层策略。所以需要对芯片进行编程,配置策略,实现协议,当然就会存在固件。由于USB PD协议仅使用CC线进行通信,所以芯片厂商也会通过CC线对USB PD芯片进行固件烧录,在烧录方式上目前存在三种形态。

第一种是原厂单次烧录(OTP),这种芯片只在出货之前被烧录一次,不会被再次修改,也就是说不存在烧录恶意固件的问题。同时也因为只支持一次性烧录,所以这种协议芯片往往只会兼容标准的、成熟的快充协议,后续如果出现其他快充协议,协议芯片很难兼容。

第二种是开放式的多次烧录(eFlash/MTP),这种协议芯片配置灵活,可以利用开发工具修改固件,完成对新快充协议的兼容以及修复后续出现的BUG,出货量较大。不过这种芯片对应的开发工具可以比较容易买到,存在较大安全风险。

第三种是加密式的多次烧录(eFlash/MTP),芯片配置同样非常灵活,不过只有掌握了密钥才能获得固件更新的权限,而密钥一般都有充电器厂商保管。在技术层面,这样既保证充电器对BUG的修复能力,又能保护充电器不会被恶意更改程序,是USB PD快充充电器的最佳选择,但是如果厂商将密钥存储在烧录软件本地或者烧录设备中,也有可能存在密钥泄露的情况。

所以,USB PD协议的安全性主要取决于芯片厂商的取舍,以上三种形态都在一定程度上牺牲了产品的功能性或者安全性,至于如何去平衡功能性和安全性,这是开发人员和安全研究人员一直需要思考和面对的问题,我们要知道, 没有绝对的安全

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表德赢Vwin官网 网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分