前言
本文档介绍了面向STM32Cube的STM32 USB-PD（电力传输）软件扩展，参考X-CUBE-USB-PD。
USB Type-C™是最新的USB连接器生态系统，能够满足平台和设备不断变化的需求，同时保持USB的功能优势。
USB Power Delivery协议嵌入到了USB Type-C™连接器中，从而可以轻松连接/断开USB线缆，实现很多数据传输以外的功能。此协议能够传输超过常规5 V / 1.5 A的电压/电流，最大功率供应为100 W。
STM32 USB-PD包（X-CUBE-USB-PD）包含一个库（二进制格式）和以STM32F0设备作为USB Power Delivery微控制器的应用示例。可扩展到其他STM32系列。
该软件包包含的示例涵盖了大部分应用用例，允许用户基于USB-PD（供电方，受电方，和双角色端口）开发应用。
该库及相关示例可用于STM32F0设备以及专用P-NUCLEO-USB001扩展板（包含模拟前端和USB Type-C™连接器）。
本文档介绍了如何使用USB-PD库实现常规用途，以及创建自定义应用。它包含了以下专题，以简化此库的使用：
• USB-PD标准概述
• USB-PD库架构
• USB-PD堆栈使用描述
• 如何使用此库设置USB-PD应用。


1受电方概述
1.1缩写和缩略语

1.2参考
•通用串行总线电力传输规范，版本2.0，2016年3月25日
•通用串行总线Type-C线缆和连接器规范1.2，2016年3月25日
表1. 缩略语列表
术语 意义
API
应用编程接口
CAD
线缆检测模块
CLI
命令行接口
DFP
下行端口
DPM
设备策略管理器
DRP
双角色端口
FW
固件
HW
硬件
PD
供电
PE
策略引擎
PRL
协议层
UFP
上行端口
USB
通用串行总线
VDM
供应商定义信息DocID029258 Rev 1 [English Rev 2] 7/35
UM2063
USB-C PD架构
34
2 USB-C PD架构
2.1
架构概述
USB电力传输规范文档定义了PD设备（供电方或受电方）的通信层，如图 1中所示。
图1. USB电力传输架构
假定一个具有PD功能的器件至少具有一个端口，可以是：
•
上行端口（UFP）
– Sink电源（受电方）。
–
可选source电源（受电方 / 供电方）。
–
可选择通过USB进行通信
–
利用SOP包通信。
•
下行端口（DFP）：
– Source电源（供电方）。
–
可选Sink电源（供电方 / 受电方）。
–
可选择通过USB进行通信。
–
利用SOP包通信
–
可选择利用SOP包通信
MS41457V1
ᯯ⭫ב
਍⭫ᯯ
VBUS/CC
䇴༽ㆌ⮛㇗⨼ಞ
ㆌ⮛ᕋᬄ
অ䇤
⢟⨼ቸ
䇴༽ㆌ⮛㇗⨼ಞ
ㆌ⮛ᕋᬄ
অ䇤
⢟⨼ቸUSB-C PD架构
UM2063
8/35 DocID029258 Rev 1 [English Rev 2]
在USB产品可支持USB Power Delivery协议的场合中，USB DFP最初是Source，而USB UFP
最初是Sink，尽管USB-PD可以实现Source/Sink和DFP/UFP的功能交换。
注： 在一对端口之间，每个PD通信中只有一个Source端口和一个Sink端口。
2.2 USB-PD层
•
设备策略管理器（DPM）
DPM的作用是管理USB Power Delivery端口所用的电源。在供电方应用中，它为受电方
送电，而在受电方应用中，则向供电方要电。
一旦建立了Explicit Contact，DPM还允许交换VDM消息。Device Policy Manger是
USB-C Power Delivery Stack的上一层级。
•
策略引擎（PE）层
Policy engine（PE）的作用是根据发送的消息及其预期响应来驱动消息序列。它支持
协商电源，为电力交换建立Explicit Contract。
接受或拒绝请求取决于DPM对特定电源配置文件的响应。
PE还可以处理Vendor Defined Messages流，允许根据供电方和受电方所支持的功能，
发现、进入或退出指定模式。
•
协议（PRL）层
PRL层的作用是驱动消息构建、发送和接收（与消息性质无关）。它允许对消息流进行
检查，以检测通信错误。
PRL层是PE和PHY之间的包装层。
•
PHY层
PHY层负责通过CC线发送和接收消息。它具有信号收发器，可在电线上叠加一个信号。
它负责管理线路上的数据并避免冲突，利用CRC检测消息中的错误。
注： 关于USB Power Delivery协议的更多信息，请参考第 1.2节中的官方规范文档。DocID029258 Rev 1 [English Rev 2] 9/35
UM2063
USB-C PD架构
34
2.3
消息流
从设备发送的每个消息都应该由GoodCRC消息应答。这使得接收方可向发送方确认：其消息
已被正确接收，并将由上层进行处理。
接收到的错误消息应被忽略，在持续发生通信错误的情况下，软件复位可重置协议参数，以
重新建立通信。如果错误仍然存在，则执行系统的硬件复位。
正常情况下，协商供电合同应按照图 2中所示的顺序进行。