★ FEATURED ARTICLE 做了这么多年嵌入式真正被反复追问又很难几句话讲透的协议USB PD绝对算一个。充电头、笔记本、手机快充、便携屏、电动工具甚至最近两年很火的储能电源表面都写着PD快充可真要你把协商流程、电压档位、PPS机制这些细节讲明白不少工程师也是一知半解的状态。我前几年做一款大功率便携显示器的时候被这个协议折腾过好几回后来专门抽了两周时间把USB PD 3.1规范从物理层到策略层过了一遍又用协议分析仪实测了一堆设备的协商过程总算是把这套机制摸透了。这篇就把当时梳理的核心知识点和踩过的坑整理出来给准备上手USB PD协议开发或者调试的同行做个参考。1. USB PD到底在解决什么问题1.1 从5V到240W充电协议的演进逻辑想理解USB PD协议的价值得先回到USB充电的“石器时代”。早期USB 2.0时代标准下游端口只能提供5V/500mA也就是2.5W。这个功率给个U盘、鼠标供电绰绰有余但给平板甚至笔记本供电就完全不够看了。于是各家开始搞私有快充高通QC、联发科PE、OPPO的VOOC、华为的SuperCharge还有一堆手机厂自己的骚操作。这些方案的共同点是电压电流协商逻辑完全私有换个品牌的充电器就废掉甚至同一品牌不同代的快充协议都未必兼容。行业太需要一套统一的、可扩展的供电协商标准了。USB PD就是在这个背景下由USB-IF推动制定的。它的核心思路非常直白与其让每个设备都怼在5V上抢电流不如让供电双方动态协商一个合适的电压和电流组合。PD 2.0时代定义了五档固定电压5V、9V、12V、15V、20V最大20V/5A即100W。PD 3.0在档位基础上引入了PPS可编程电源让电压可以按20mV步进连续调整给手机直充省掉了DC-DC转换损耗。PD 3.1更进一步在SPR标准功率范围之外新增EPR扩展功率范围把上限推到48V/5A也就是240W。一个Type-C口从几瓦的小耳机到240W的游戏本通吃。1.2 为什么说USB PD是“协议工程”而不只是“充电协议”不少人觉得USB PD就是“充电快”其实这是误解。USB PD的准确名称是Power Delivery它做的不只是传输功率而是一整套电源管理协商机制。它跑在一根Type-C的CC线上和USB数据线、DP视频线共用同一个物理接口。这意味着它必须和数据传输、角色交换、线缆识别这些功能协同工作。举个实际场景你把显示器通过Type-C接到笔记本上同时显示器还要给笔记本反向充电。这里面同时发生了几件事USB数据角色协商决定谁当HostDP Alt Mode协商决定视频信号走哪些引脚USB PD协商决定显示器能否、以多大功率给笔记本供电。三个协议栈在同一根线上协同工作任何一个环节出错都会导致功能异常。这就是为什么做USB PD开发不能只把它当单纯的“充电协议”来看它本质上是Type-C生态里的“电源管理层”和各路协议都有交集。1.3 谁最需要啃透USB PD协议坦白讲如果只是做个小产品接充电头取5V用个CC电阻下拉就够了完全不需要深入PD。但如果你做的是这些方向USB PD协议就是绕不开的必修课大功率嵌入式设备便携屏、迷你主机、电动工具、机器人底盘这些设备要吃9V、12V、20V必须主动协商高电压档位电源类产品充电器、车充、储能电源、多口充电站作为Source端要正确下发能力并响应Sink的请求电池供电产品特别是带Type-C充电口的设备需要理解PPS直充机制才能设计高效率的充电链路Type-C周边调试做线缆、转换头、eMarker识别得搞清楚SOP消息和线缆通信我见过太多项目卡在“充电器插上去只有5V”这个现象上原因就是PD协商没配对。这类问题靠猜是解决不了的必须回到协议本身去排查。2. 协议核心机制从CC线到功率协商逐层拆解2.1 CC线一根线承载的握手与身份识别USB PD的消息不是通过VBUS或者D/D-传输的它专门走Type-C接口的CC线也就是Configuration Channel。这也是USB PD和传统充电协议最大的物理层差异。Type-C接口上有两组CC引脚CC1和CC2。因为Type-C插头正反可插所以设备必须能识别CC1/CC2哪个被连接。连接检测的机制是靠上下拉电阻实现的作为Sink的下行设备会在CC引脚上接一个5.1kΩ下拉电阻到地作为Source的供电端则在CC1/CC2上各接一个上拉电阻到VBUS。Source检测到CC线上的电压被拉低就知道有Sink插进来了然后开始供电。如果CC线电压没被正确拉低Source就不会打开VBUS设备自然没有电。除了连接检测CC线还有一个隐藏功能eMarker线缆识别。支持5A电流或USB4/雷电的线缆内部会有一颗eMarker芯片Source通过CC线上的SOP消息去读这个芯片里的信息确认线缆的最大电流能力、传输速率、是否支持EPR等。这也是为什么很多线缆虽然Type-C口长得一样实际能力天差地别。2.2 消息机制控制消息和数据消息如何协同USB PD协议的分层结构有点像网络协议栈最底层是物理层负责在CC线上做BMC双相标记编码速率在300kbps左右往上是协议层负责把消息封装成包带CRC32校验和重传机制再往上是策略引擎负责决定当前设备应该处在什么状态、要不要同意对方的请求。USB PD消息分为两大类控制消息和数据消息。控制消息不携带数据对象通常用于流程控制比如GoodCRC是接收方对每个数据包的ACK确认Accept表示Source同意Sink的请求PS_RDY表示电压已经切换到目标值。数据消息则携带具体内容最核心的是Source_CapabilitiesSource发送自己支持的PDO列表和RequestSink从中选择并请求某个档位。为了保证可靠性USB PD对每个消息都有严格的超时重传机制Sender发送消息后如果Receiver没有在规定时间内回复GoodCRCSender就会重传重传达到上限还没收到确认就会触发Hard Reset一切回到默认的5V状态重新协商。这套机制和TCP协议的确认重传思路非常相似理解TCP的人上手USB PD的协议层会特别快。2.3 功率协商从Source_Capabilities到PS_RDYUSB PD最核心的一段“对话”就是功率协商过程。我用实际抓包时的顺序把它完整拆开。第一步是连接建立后Source端会自动发送Source_Capabilities消息携带一串PDOPower Data Object每个PDO就是一个可供选择的电压电流档位。典型PDO可能是5V/3A、9V/3A、12V/3A、15V/3A、20V/5A。Sink端收到能力列表后根据自己当前的负载需求选一个PDO然后构造Request消息发回去。Request不是简单说“我要20V”而是通过RDO结构体告诉你我选了第几个PDO期望的工作电流是多少峰值电流需求是多少是否需要解锁EPR模式等。Source收到Request后如果觉得自己能提供就回Accept如果觉得这个请求超纲了会回RejectSink就得换一个档位重新请求。大多数人以为到这里就完事了其实最关键的步骤在后面。Source回Accept之后并不会立刻把VBUS拉到目标电压而是要先回一个PS_RDY消息告诉Sink“我准备切换了”然后才在规定的迁移时间内把电压从当前值升到目标值。Sink收到PS_RDY后也要在一个规定时间内把自己的负载切换到新电压下工作。这个流程保证了双方对“电压什么时候变”有一致的认知避免Sink在Source还没升压时就按照高压去设计电路而导致过压损坏。这套协商机制的核心价值在于风险可控源端不盲目升压汇端不强拉电压每一个动作都是握手确认后的结果。即使协商过程中出现了异常还有Hard Reset兜底让系统回到5V安全状态而不是直接烧设备。2.4 PPS与PD 3.1追求更精细的功率控制PPS是USB PD协议里一个容易被低估的功能。它在PD 3.0引入本质上是把“源端电压调节权”交给了汇端。PPS模式下Sink可以动态要求Source把输出电压在某个范围内按20mV的步进调整并且Sink也约束源端的最大输出电流。这对手机电池直充来说价值极大充电头不再需要固定输出一个电压然后靠手机内部的降压电路去适配电池电压而是让充电头直接输出和电池电压接近的电压仅留出一点裕量系统损耗一下就降下来了。PD 3.1的EPR扩展更激进把电压档位推到28V、36V、48V最大240W。但EPR不是想进就进的它要求Source端在SPR协商完成后再发送EPR Source_CapabilitiesSink端用特定的EPR Request去请求而且线缆必须是支持EPR的eMarker线缆。这个设计是为了隔离风险防止普通线缆或老旧设备误入高压状态。3. 实操1小时搭起USB PD调试与抓包环境3.1 硬件准备与工具选型说句实在话USB PD协议调试最大的门槛不是看不懂协议而是没有一个能直观看到协商过程的工具。我的建议是准备一套组合方案PD诱骗器或带TCPM的Type-C开发板用来主动触发协商、提取特定电压。市面上像CH224K这类PD Sink芯片十几块钱就能买到支持PD3.0和PPS非常适合做验证协议分析仪这是我看协议的头号功臣。常见的有Total Phase的PD分析仪或者带PD解码的兼容分析仪。它能直接在电脑上显示完整的消息序列、时间戳和每个字段的解析结果省掉手动阅读规范的大量时间逻辑分析仪如果预算有限或者想更深入理解物理层一台采样率足够高的逻辑分析仪也能用。USB PD的BMC信号速率约300kbps建议用至少4M采样率以上的设备抓CC线上的波形然后手工解码或者用带BMC解码的软件玩协议分析仪抓包你得理解“抓包是一次无侵入监听”。分析仪只是并联在CC线上观察通信过程不主动参与消息交互所以看到的是真实世界里设备之间的协商行为。这和软件调试里挂个断点有点类似但USB PD抓包更侧重观察而不是干预。3.2 实测一次完整的PD协商过程我拿一棵支持PD3.0的充电头和一块PD诱饵板做了次实测。用分析仪监听CC线上的通信观察到的完整事件序列大概是这样的接入瞬间Source检测到Sink的5.1k下拉电阻启用VBUS并提供默认5VSource发出Source_Capabilities携带6个PDO5V/3A、9V/3A、12V/3A、15V/3A、20V/5A以及一个PPS档位Sink端诱饵板收到能力列表根据预设目标选择20V档构造Request请求里面指定object position为5也就是第5个PDO请求电流设为5ASource校验请求合法后回复Accept然后经过短暂延时发送PS_RDYVBUS电压从5V爬升到20V整个过程大约几十毫秒Sink端监控到VBUS到达目标电压后切换内部预调节器如果只做一次抓包这些事件在分析仪软件里往往几秒钟就刷完了。但这短短几秒背后涵盖了连接检测、能力发布、请求协商、电源切换四个环节。把这一套流程在脑内过一遍比你翻十遍协议规范都管用。3.3 用开发板实现一个最简单的PD Sink不想用诱饵芯片也可以自己写代码实现Sink端PD逻辑。以STM32加一颗物理层收发器为例核心逻辑其实很简单上电后配置CC引脚利用ADC检测CC1/CC2电压变化判断连接事件当检测到Source的Rp上拉后进入等待Source_Capabilities状态收到能力列表后解析PDO根据预设策略选一个电压档构造Request发出去收到Accept和PS_RDY后打开负载开关并切换到目标电压下的工作模式。实现时最需要注意的是消息头的8位消息类型和版本字段对齐以及每条消息都要在1秒内做Ack校验。很多初学者第一次写PD代码最容易挂的地方是收到Source_Capabilities后没有及时回GoodCRC导致Source重传或者直接放弃。我自己曾在一个项目里因为遗漏了GoodCRC发送逻辑导致设备反复Hard Reset后来靠分析仪抓包才发现问题出在协议层的应答而不是电源电路。4. 开发调试中的常见问题与排查技巧实录4.1 一张表看清高频故障把这些年调试USB PD协议遇到的高频问题整理成一张速查表遇到现象直接对照排查故障现象可能原因排查手法充电器永远只输出5VCC线没接好、Sink未正确下拉5.1k用万用表测CC电压确认电阻连接协商成功后电压频繁跳动线缆接触不良、VBUS纹波过大换线缆示波器观察VBUS波形能协商到20V但电流上不去线缆不支持5A、eMarker缺失查看线缆eMarker信息换认证线缆设备反复重启、Hard Reset循环GoodCRC应答遗漏、协议状态机异常用协议分析仪看是哪条消息没回Ack请求PPS档位后电压不更新源端对PPS支持不完整、目标电压超范围核对PPS PDO的电压上下限PD 2.0适配器接PD 3.0设备不工作版本消息兼容性问题在协议层增加版本协商兼容处理4.2 CC线物理层翻车现场有一类问题特别容易让人抓狂协议分析仪看一切正常但设备就是带不动负载。后来排查到根源是CC线的物理连接质量。Type-C母座的CC引脚非常细如果焊接不良或者线缆过长CC线上的BMC信号会被严重衰减导致消息频繁CRC校验失败。这种情况下协议分析仪因为是短接线所以看着正常但旁边的实际负载一走电流就出问题。我的经验是做PD协议调试时永远不要忽略线缆和连接器的质量。PD协商是一个高频信号叠加在电源线上的过程线缆寄生电感和接触电阻会同时影响信号完整性和电源瞬态响应。建议调试时用短线、好线排除线缆因素后再去怀疑协议逻辑。4.3 充电永远不会一次匹配谈Sink请求策略设计很多Sink设备的请求策略写得过于简单固定选最高电压档位然后期望源端满足。实际工程中不是这样的。Source可能同时充电一个笔记本和一个小功率设备适配器内部已经限流了也可能是二十块的廉价充电头PDO标注得很夸张但实际带载能力很差。这些情况如果Sink端只是盲目请求高压大电流轻则Power Delivery协商失败重则把充电头拉垮甚至烧毁。成熟的Sink请求策略通常分三层设计额定档位优先、降级档位兜底、PPS动态调节。启动负载前先请求中等电压确认链路稳定再逐步升压遇到Source拒绝时按优先级降级到低一档而不是反复请求同一个被拒的档位。这个策略写起来不难但能显著提升设备和不同充电器之间的兼容性。4.4 抓包数据怎么看才不白抓协议分析仪给你一堆时间戳和消息列表如果不能从里面读到有价值的信息那和没抓一样。我看一套PD协商数据习惯按这三个维度去扫第一看消息序列完整性。正常协商应该严格按Source_Capabilities→Request→Accept→PS_RDY的顺序走。任何中间的异常分支都要追查。第二看重复和重传。一条消息反复出现说明对端没有正确回复GoodCRC重点查物理层和CRC。第三看时间参数。Source_Capabilities发送后Sink响应太慢会导致超时说明Sink端解析或决策耗时过长这时候需要优化固件而不是加电容。每次都按这三个维度扫一遍基本能把绝大多数PD问题定位到具体层。很多工程师拿到数据只会看“额电压上去没有”那就浪费了分析仪的真正价值。5. 一些适合放在最后的话做USB PD协议研究和调试这几年我最深的体会是这个协议看起来复杂但一旦理解了“Source下发能力、Sink主动请求、双方确认后执行”这套核心设计哲学后面所有细节都顺理成章了。它本质上是把“我要什么、我能给什么、双方确认后共同执行”这层沟通逻辑标准化了。工程上遇到问题先回到这套逻辑去问自己是能力没下发、请求没到位还是确认流程断了十有八九能快速缩小排查范围。我个人比较推荐的做法是项目启动阶段就准备好一套PD抓包环境哪怕是一块几十块钱的诱饵板加一个二手逻辑分析仪。不要等到产品原型调不通再来补课USB PD这种“看不见摸不着”的通信协议借助工具把协商过程可视化效率提升是立竿见影的。而且实测下来不同充电头、不同线缆的PD实现细节千差万别协议分析仪里的真实数据比规范文档更能帮你找到预料之外的兼容性问题。后面如果你们也在做Type-C供电相关的产品建议从这次聊到的协商流程开始把手上有的充电头一个个抓一遍很快就能建立起对这个协议更完整的直觉。
阅读完成 · 觉得有帮助？
