USB PD规范 第二章浓缩了USB PD规范的精华,走马观花地讲了USB PD协议的工作原理。 ![]()
2.1 USB PD介绍 在USB PD中,一对直连的端口用USB Type-C连接器中的CC线作为通讯信道来协商出电压,电流以及在Cable里面供电的方向。这种被采用的机制,独立于其它的用来协商 USB 电源的操作方式。 USB PD 也会充当一个边带信道使其能够支持标准或厂家自定义的模式操作。工作 Mode 是与 SVID 联系在一起的。在 PD 协议中结构化的 VDM Message 可以被用来发现支持的 SVID 和 Modes,当有需要的话,同样支持 Modes 的进入与退出。多个 Active Modes 可以同时工作。 一旦用这个标准协商出来的契约的关系,都将替换任何之前使用的USB2.0、USB3.1、USB Type-C1.2 或 USB BC1.2 机制所协商出来的供电关系。当处于 PD 模式的时候,将会有个契约关系(既可以是显性契约也可以是隐性契约的关系)在工作中决定着可用的供电等级和方向。当一对正常工作在 PD 模式下的端口断开连接后,将引起系统复位或 SRC 端移去供电的电源 (除了发生在 PRS 和 FRS 过程之中,当起初的 SRC 去掉供电为了让新的 SRC 开启供电)。 显性契约关系协商的过程开始于 SRC 发起一系列的供电能力,然后 SNK 从其中申请一个特定能力的请求,接下来 SRC 接受了这个申请。 隐性契约关系是指在特定状态下的指定供电等级(比如在 PRS 和 FRS 过程中或者在它们发生之后)。由此可以知道,隐性契约关系的状态只是暂时的。端口间需要立即协商出新的显性契约来。 每个供电的一方都有个本地策略,管理着向对端端口的功率分配。SNK 也有自己的本地策略来管理应该吸收多少电能。基于 USB 所制定的系统策略允许对本地策略的更改,因此在系统中可以管理供电的分配。 当具有 PD 能力的设备互相连接成功之后,DFP 和 UFP 初始为 USB 默认的工作状态。DFP 提供了 vSafe5V,UFP 吸收电流与 USB2.0、USB3.1、USB Type-C 或者USB BC1.2 相关标准定义的规则相一致。在 PD 协商发生之后,可以输出比标准定义中更高或更低的电压和更高的电流。它也可以完成 PRS 或 FRS 来交换电源供给的角色,从而使得 DFP 变成受电一方,UFP 变成供电那一方。同时可以通过 DRS 使得 DFP 变成了 UFP,反之亦然。通过执行 VCONN Swap 来改变 VCONN 供电的方向。 在显性契约关系建立之前,SRC 可以发现连接上的线缆能力和特性。了解在 USB Type-C 1.2 中被标记 5A 能力的线缆和其它线缆的一些细节比如支持的速率这一点很重要。发生在端口连接上的初始,在显性契约关系建立之前,DFP 同时也是SRC 的情况下开始进行 Cable discovery。PRS 和 FRS 之后,显性关系建立之前,在 UFP 为 SRC,隐性契约在工作的情况下,也是有可能进行 Cable discovery 的动作。 一旦是显性契约工作的状态下,只有 DFP 允许和连接上的 Cable 进行通讯。不仅包括了 Discover identity,也包括了 Cable 所支持的 Discover SVID,Discover Mode,Enter Mode 和 Exit Mode 模式。
2.2 章节概述 此规格包含了下面的部分: ![]() 2.3 更新和兼容性 下面是对 PD3.0 与 PD2.0 主要变化的总结: 2、原来的 Profile 丢弃不用,取而代之的是 PD 的供电模式(see Section 2.7.9)。
3、BFSK 支持已弃用的设备,包括传统电缆,传统连接器,传统的电池耗尽的操作和相关的测试模式。 4、Extended Message 数据的有效载荷长度达到了 260bytes(see Section 6.2.1.2)。
5、只有 VCONN SRC 允许和 Cable Plug 进行通讯(see Section 2.5.4) 6、 SRC 尝试协调尽可能地避免碰撞使 SRC 和 SNK 中的任意一个端口能够发起 AMS 的序列。
7、删除了 Attention 命令的时间限制。
8、附加的状态和发现
9、无源电缆,有源电缆和 AMA VDO 中字段的改变表明了将 Structured VDM 更改到 2.0 的版本。 10、支持与 USB 安全相关的请求与响应。 11、支持 USB PD 固件的更新请求与响应。 12、系统策略在当前的引用。
USB PD 标准的 3.0 版本被设计用来完美兼容 USB 2.0 的系统,此系统在 USB Type-C 1.2 连接器上使用 BMC 的信号是和 2.0 版本的硬件是一致的。 这份标准强制要求了所有 3.0 版本必须完全支持 USB PD 2.0 的操作。它们必须发现对端或 Cable Plug 所支持的版本,然后用最低,常见的版本号使回复到与之对应的状态。(see Section 6.2.1.1.5) 这个标准规定了 Extended Message ,其包的长度达到了 260 bytes(see Section 6.2.1.2)。这些 Message 要比目前 PHY HW 中包的长度要长。为了可以支持 2.0 版本的基础系统,分块机制被强制执行以便 Message 被限制到 PD 2.0 版本的尺寸,除非发现两个系统都可以支持最长包的收发。 这个标准包括了 Vendor Defined Objects(VDO) 的变化用来发现识别 passive/active cable 和 Alternate Mode Adapters(AMA)(see Section 6.4.4.2)。 为了能使系统决定用哪个 VDO,结构化的 Vendor Defined Message (SVDM)的版本号递增到 2.0。 如果变得有需要的话,版本号也已经包含了 VDO 本身,来促进接下来的变化。
2.4 USB PD 支持设备 在 Figure 2-1 中可以看到一些具有 USB PD 能力的设备(a Host, a Device, a Hub, a Charge)。这些都是仅供参考,不会限制基于这份标准而建立的产品可能的配置。 ![]() 每一个具有 PD 能力的设备被认为至少组成了一个端口。Providers 被认为是 SRC, Consumers 被认为是 SNK。每个设备包含了一个甚至更多下面的要素。
UFPs 可以是:
DFPs 可以是:
A SRC that 可以是:
A Sink 可以是:
A VCONN SRC 可以是:
2.5 SOP* 通讯 2.5.1 Introduction 2.5.2 SOP* Message Collision Avoidance 2.5.3 SOP Communication 2.5.4 SOP’/SOP” Communication with Cable Plug 在连接时 VCONN SRC 是 SRC/DFP,然而这些所有的模式都可以通过 PD Message 来改变。 Cable Plug 不会识别 SRC 和 SNK 之间 SOP Message 的通讯。Figure 2-2 部分介绍了 VCONN SRC(DFP/UFP)和 Cable Plug 之间进行 SOP*通讯的用法。 所有的 SOP*信息通讯都发生在 CC 上。这意味着必须协调 SOP*信息通讯来防止阻碍其它重要的通讯。对于不识别 SOP/SOP’/SOP”的产品来说,这一点看上去像一个非空闲的信道,从而导致丢包和重传。 两个端口之间是优先进行通讯的,意味着与 Cable Plug 的通讯是可以被打断的,但不会导致 Soft Reset 和 Hard Reset 的产生。 当没有契约或者默认契约关系在工作时(例如.在 PRS 或者 FRS 之后)SRC(既可以是 DFP 也可以是 UFP,但必须是 VCONN SRC)可以用 SOP’的包来与 Cable Plug 进行通讯,以此来发现并获得它的特性。在这个阶段所有与 Cable Plug 的通讯都是由 SRC 端发起和控制,以此防止和 SOP*的包形成冲突。SNK 是不会和 Cable Plug 进行通讯的,即使它是 DFP,也要丢掉任何收到的 SOP’类型的包。 当明确的契约关系在工作时,VCONN SRC(可以是 DFP 也可以是 UFP)可以用 SOP’/SOP”的包和 Cable Plug 进行通讯。在这个阶段所有与 Cable Plug 的通讯都是由 VCONN SRC 发起,以此来防止和 SOP*的包形成冲突。不是 VCONN SRC 的那个端口则不会与 Cable Plug 进行通讯,同时也不会识别任何收到的 SOP’/SOP” Message。只有是 DFP,同时也是 VCONN SRC 的时候,可以允许发送 SOP*来控制进入或退出 Mode 及管理相应的工作模式(。通过发送 Discover Identity 来读取 Cable 的信息,如果是 Active Cable,则继续发送 Discover Mode/Enter Mode/Exit Mode 来控制 Mode 的整个过程) ![]()
Note: Cable Plug 既可以和 DFP 连接,也可以和 UFP 连接。 2.6 操作概述 SRC/SNK,DFP/UFP,VCONN SRC 的模式都可以通过 PD Message 进行转换。同时支持 SRC 和 SNK 的端口叫做 DRP,同时支持 DFP 和 UFP 的端口叫做 DRD。 下面的部分描述的是高等级的工作来承担 DFP,UFP,SRC,SNK 的角色。这些部分不会描述不被允许的工作状态;但如果一种特定的行为没有描述到,那就很可能没有被这个标准所支持。 PD 如何在一个 PD USB 设备上绘制自己状态的详情请看 9.1.1 章。 2.6.1 SRC Operation SRC 工作状态的不同取决于连接状态:
1. 对一个 SRC_Only 的端口来说,SRC 会检测 SNK 有无连接上。 2. 对 DRP 端口来说会切换使其变成 SRC 以完成和 SNK 的连接。 3. 在 SRC 端设置 VBUS 到 vSafe5V。
1. 在发 SRC_CAP 之前,SRC 可以检测连接上的 Cable 的类型,然后根据检测到的 Cable 的类型来改变它的通告能力。 2. SRC 会定期的在每个 tTypeCSendSourceCap 时间内通过向对端发送SRC_CAP 来通告自己的供电能力。
1. 有下面两种中的一种说明检测到存在的对面端口具有 PD 功能。
1. SRC 从 SNK 那边收到 Request Message,然后用 Accept 来响应 SRC发出的 Request。如果是一个合法,有效的 Request,当准备好供电给SNK 协商好的 Power 之后,SRC 会发出 PS_RDY Message,这个时候显性契约就建立了。 2. DFP 不会生成 SOP’或 SOP ”的包,也不需要检测 SOP’/SOP”包,就算检测到也会将其丢掉。
1. SRC 会处理和响应(如果需要的话)所有收到的包,无论何时,当它本地策略需要的时候会发送恰当的包。 2. 当 SRC 也是 VCONN SRC 的时候,在没有其它 SOP 通讯时,可以在任何时候用 SOP’或 SOP”与 Cable Plug 进行通讯。 3. 当端口既是 SRC,同时也为 DFP 时 4. 如果 SRC 端口是一个多口的系统
1. 当 SRC 检测到线路断开后,会在 tSafe5V 的时间内将电压降到 Vsafe5V, 在 tSafe0V 的时间内降到 Vsafe0V(SRC 通过检测 ADC 的值来看线路有无断开)。 2. 当 SRC 在 tReceive 时间内,收到为响应 Message 而发出的 GoodCRC包,在此过程中检测到了错误。 3. SRC 为了进一步尝试通讯但没有收到响应表示出现了错误。 4. 在 Power 协商过程中出现的错误会自动地产生 Hard Reset 为了将Power 维持在默认的等级(5V)。
1. 当协议层出现错误时,会引起端口中的任意一个发出 Soft Reset.从而复位 counters, timers 和 states,但这个动作不会改变协商好的电压,电流或端口的模式(比如 SRC,DFP/UFP,VCONN SRC)也不会导致退出现有的工作模式。 2. 当线路中出现严重错误的时候,两个端口中的任意一个都可能会发出Hard Reset 的信号。 3. 在 Hard Reset 产生后,寄望于对端可以在 tNoResponse 的时间内对 Hard Reset 请求做出响应。如果未有响应,进行 Hard Reset 累加(最大为 2)直到 SRC 进入 Error Recovery 状态。 2.6.2 SNK Operation
1. SNK 会通过对端有无输出 vSafe5V 来判断连接。 2. 对 DRP 端口来说会切换使其变成 SNK 以完成和 SRC 的连接。 3. 一旦 SNK 在 VBUS 上检测到 vSafe5V 的存在,它通过等对端是否发出 SRC_CAP 来判断对端为具有 PD 能力的 SRC。 4. 如果 SNK 没有在 tTypeCSinkWaitCap 时间内收到 SRC 发出的SRC_CAP,通过发出 Hard Reset 信号寄望于 SRC(具有 PD 能力)可以发出 SRC_CAP。 5. SNK 不会生成 SOP’或 SOP”的包,也没有必要检测 SOP’或 SOP”的包,同时不会去识别它们。
1. SNK 收到了 SRC_CAP 的 Message,然后用 GoodCRC 响应。 2. SNK 不会生成 SOP’或 SOP”的包,也没有必要检测 SOP’或 SOP”的包,就算检测到也要将其丢掉。
1. SNK 从 SRC 那边收到 SRC_CAP Message,然后用 Request Message向 SRC 发出供电请求。如果是一个合法,有效的 Request, SNK 收到了对端的 Accept Message,当准备好供电给 SNK 协商好的 Power 之后,同时会收到 SRC 发出的 PS_RDY Message,这个时候显性契约就建立了:
1. SNK 会处理和响应(如果需要的话)所有收到的包,无论何时,当它本地策略需要的时候会发送恰当的包。 2. 当 SNK 的申请能力需要改变的时候,会通过发新的 Request Message 来通知 SRC。SNK 申请的电压应该是 SRC 发出的电压能力中的一个,即使它是被 USB2.0,USB3.1,USB Type-C 1.2 或 USBBC 1.2 所支持的 vSafe5V 输出,为的能够协商更高的电压: (2)假如 SNK 申请的电压能力不在 SRC 所能提供的范围内,那么将以默认的第一个进行申请,SNK 将它改变申请的动作通知最后一个。 3. SNK 在 CC 线路上总是 asserted RD。 4. 当端口电力模式为 DRP 时,SNK 可以发起或收到电力模式转变的请求。在 PRS 之后,SNK 将会变成 SRC,在明确的契约关系形成之前,由默认的契约关系暂时代替其工作。 5. 当端口数据模式为 DRD 时,SNK 可以发起或收到数据模式转变的请求。在 DRS 之后,DFP 会变成 UFP.端口的电力模式还是 SNK,同时 VCONN SRC 也不会发生改变。 6. SNK 可以发起或接收转换 VCONN SRC 供应的请求.在 VCONN 交换期间,是可以被两端所运用的(中断之前)。此时端口的电力模式和数据模式没有发生改变。 7. 当 SNK 也是 VCONN SRC 的时候,在没有其它 SOP 通讯时,可以在任何时候用 SOP’或 SOP”与 Cable Plug 进行通讯。 8. 当端口既是 SRC,同时也为 DFP 时
1. 当 SNK 检测到线路上没有 VBUS 输出时,这就意味着 PD 连接的结束,除非是由于 Hard Reset, PRS,FRS 中的一个导致状态回到 vSafe0V。 2. SNK 检测到插头的移除,然后开始进行放电。 3. 当 SNK 在 tReceive 时间,收到了为响应 Message 而发出的 GoodCRC 包的过程中检测到了错误。 4. 在 Power 协商过程中出现的错误会自动地产生 Hard Reset 为了将Power 维持在默认的等级(5V)。
1. 当协议层出现错误时,会引起端口中的任意一个发出 Soft Reset。从而复位 counters, timers 和 states,但这个动作不会改变协商好的电压,电流或端口的模式(比如 SRC,DFP/UFP,VCONN SRC)也不会导致退出现有的工作模式。 2. 当线路中出现严重错误的时候,两个端口任意一个都可能会发出 Hard Reset 的信号。
2.6.3 Cable Plug
1. 在任何时候,通讯都可以被中断。 2. 在 VCONN SRC(DFP/UFP)与 Cable Plug 的通讯的时候,没有时间超时的说法。 3. Cable Plug 准备响应可能的重复请求。
1. Cable Plug 检测到 Hard Reset 信号后来判定 SRC 和 SNK 已经 Reset,之后 Reset 自身(相同的掉电过程)。 2. Cable Plug 检测到 Cable Reset 的信号来决定是否需要 Reset 它自身(相同的掉电过程)。
2.7 Architectural Overview 架构概述
![]() 此外,具有 USB PD 能力的设备同样可以作为 USB 设备在 USB 中实现通讯(see Figure 2-4)。一种任意的系统策略管理器(see Chapter 9)存在于 USB Host 与 PD设备之间的通讯中,经过 root 端口,可能地遍布在一棵树上的 USB 集线器上。在每个设备上,设备策略管理器与 USB 接口相互作用为了可以在域中提供和更新 PD 的相关信息。Note:PD 设备不需要有一个像 USB 设备那样的接口。 ![]() Figure 2-5 描述了两个连接 PD 端口的逻辑模块。另外,通讯协议 stack 部分上面也有描述包括了:
设备的策略管理器会和通信 stack 进行通讯,SRC/SNK 和 USB-C 的控制模块来管理 Provider 和 Consumer 中的资源。 Figure 2-5 说明了一个 Provider 和 Consumer 内部通讯的框架结构。DRP 的设备结合了 Provider 和 Consumer 的功能要素。Provider 也可以包括多个的 SRC端口,它们每一个都有自己的通讯 stack 和 USB-C 接口的控制。 ![]() 2.7.1 Policy 策略包括了一些逻辑模块:
2.7.1.1 System Policy Manager 任何给定的系统,系统策略管理是可选择的,非强制的。所以在没有系统策略管理的时候,USB PD Providers 和 Consumers 也可以正常工作。这一点包括了在系统中,USB Host 没有提供系统策略管理或者系统中没有任何的 USB Host。在不存在 Host 的情况下,USB PD 只是用来起到充电的目的,或给设备充电。 一个 USB Host 在没有系统策略管理的情况下,Provider 和 Consumers 可以基于 USB 的电源规则,自己独立协商出 Power, 使得在可用的电源管理选项上没有过多的限制。 2.7.1.2 Device Policy Manager 2.7.1.3 Policy Engine Policy Engine 会直接与 Device Policy Manager 相互作用为了来确定当前的 Local Policy 被执行。无论何时,当 Local Policy 发生改变的时候,Device Policy Manager 都会通知给 Policy Engine。 2.7.2 Message Formation and Transmission 2.7.2.2 PHY Layer 2.7.3 Collision Avoidance 2.7.3.1 Policy Engine 2.7.3.2 Protocol Layer 2.7.4 Power supply 2.7.4.1 Source 2.7.4.2 SNK 相关分类 |