第2章 PD协商失败的影响——不仅仅是充不进电

很多人一听到PD协商失败，第一反应就是「哦，充不进电嘛」。说实话，这个理解太窄了。我在一线摸爬滚打这些年，见过的问题远比这个复杂。充电慢、设备重启、外设不识别，这些看着八竿子打不着的问题，根因可能都是PD握手没谈拢。

这一节，我们就把这几个典型场景掰开揉碎了讲。你看完后会发现，很多疑难杂症，追到源头就是个PD协商的事。

2.1 充电行为异常——最直观的「受害者」

先说最直接的——充电出了问题。这里头又分三种情况，严重程度一个比一个高。

2.1.1 完全无法充电

这算是最严重的情况了。插上充电器，设备没任何反应，连个充电图标都看不到。我遇到过一款Type-C转接器，插上手机后就是没反应。查了半天，发现是CC线上的下拉电阻Rd焊错了位置。Source检测不到有效连接，自然就不会发起协商。

故障现象	典型根因	快速判断方法
插电无反应，无充电图标	CC线断开、Rd电阻缺失、Source未供电	万用表测量CC脚电压，正常应为0.3V-0.6V（上下拉后）
插电后反复断开重连	CC引脚接触不良、VBUS电容过大导致过冲	用示波器抓取VBUS波形，看是否有电压跌落
充电指示灯异常闪烁	协商过程中Source/Sink能力不匹配，反复重试	抓取Type-C数据线上的SOP通信报文

我个人的排查习惯：遇到这类问题，先别急着拆芯片、换协议，拿个万用表量一下CC线上的电压。很多时候就是电阻值不对。

2.1.2 充电速度极慢

这种问题更隐蔽。设备能充电，但就是慢得像「龟爬」。用户会觉得是电池老化了，或者线材不行。其实很可能是协商到了低功率档位。

举个例子。我在一个快充移动电源项目上遇到过：用QC充电头充没问题，换了个PD充电器，就只剩5V 1A。查了半天才发现，Sink端提交的Object Position请求写错了——它请求的是第2个PDO，但Source端第2个PDO是5V 3A档位。说白了就是设备自己「选错了档」。

2.1.3 间歇性中断充电

这类问题最让人头疼。充着充着突然停了，过几秒又自己恢复。用户通常会投诉「接触不良」。其实啊，很多是PD协商超时导致的。

我曾经调试过一台笔记本，充电时每隔30秒就断一下。追踪SOP报文后发现是Sink端发出的Request消息太长，超过了Source端设置的30ms超时窗口。Source没收到回复，直接切回了默认供电。嗯，这里要注意：PD协议的时序要求非常严格，差几毫秒就会出问题。

2.2 设备运行不稳定——隐藏的「杀手」

这部分是很多工程师容易忽略的。PD协商失败不仅影响充电，还会让系统运行不稳。你想想看，供电规格都没敲定，工作状态能稳定才怪。

2.2.1 系统异常重启

这个场景我在平板项目上碰过两回。设备接上PD充电器后，屏幕一亮就黑屏重启，如此循环。用示波器抓VBUS，发现电压在5V和9V之间反复跳变。

为什么会这样？

1. Source端主动发起PD协商，尝试切换到9V档位。
2. Sink端接收请求后，负载电路还没来得及调整，内部DC-DC还没适应新电压。
3. VBUS瞬间跳变，给Sink端SoC的供电纹路带来冲击。
4. SoC触发欠压或过压保护，直接重启。
5. 重启后重新协商，陷入无限死循环。

2.2.2 外设驱动异常

有些设备里的外设控制器也挂在VBUS上。比如外接鼠标、键盘、U盘，它们的供电有时候也走CC协商后的通路。如果协商失败导致VBUS电压异常，外设就可能掉线或工作异常。

我印象很深的是一个Type-C Hub项目。插上U盘后，硬盘灯闪一下就灭了，根本读不出来。排查后发现是Hub内部的PD控制器和硬盘供电时序冲突——硬盘还没完成初始化，PD协商就把电压从5V切到了12V，硬盘主控直接挂了。

2.3 外设交互失败——看不见的「断连」

说完内部影响，再说外部。PD协商失败还会导致外设无法正常识别或工作。

2.3.1 Type-C数据线交互失败

很多Type-C线材内部有eMarker芯片，需要通过Discover Identity消息来读取线缆能力。如果协商失败，eMarker信息读不出来，Source就只能按默认512mA或3A的电流来供，外设肯定带不动。

我建议排查步骤：

• 第一步：检查线缆的CC通道是否连通，确认CC1/CC2线路正常。
• 第二步：用PD测试仪抓取SOP'报文，看是否有Discover Identity请求/响应。
• 第三步：如果无响应，就是线材自身问题；如果有响应但数据错误，就是eMarker损坏。

2.3.2 DP Alt Mode外接显示器不亮

PD协议不光送电，还能跑DP信号。如果PD协商失败，DP Alt Mode也就无从谈起了。我遇到过一台笔记本，插上Type-C转HDMI线后，外接显示器始终无信号。查了半天发现是Sink端拒绝了下发DP功能的请求。

说白了就是，很多设备在PD协商阶段会检测对方是否支持DP功能。如果Source端没正确声明自己的DP能力标志位，Sink端就不开DP通路。这一来，视频信号就传不过去了。

2.4 一张图看懂PD协商失败的影响路径

你看这张图，从PD协商失败这个根因出发，三个分支覆盖了我们日常碰到的所有问题。每一个箭头，背后都是一段排查的血泪史。

2.5 各影响场景的对比与排查优先级

实战中，你不能对所有问题一视同仁。得有个优先顺序。我一般这么排：

影响类型	严重程度	排查难度	建议优先排查
完全无法充电	高	低	CC线连接、Rd电阻
充电慢	中	中	PDO请求逻辑、超时参数
间歇性中断充电	高	高	时序、消息长度、电缆屏蔽
系统异常重启	极高	高	VBUS切换时序、负载预稳
外设驱动异常	中	高	DC-DC上下电顺序、VBUS跳变
外设不识别	低	中	eMarker通信、DP能力标志位

我个人经验：优先级别光看严重程度，还要看排查成本。比如「完全无法充电」虽然严重，但通常一招就能锁定。反而是「系统异常重启」这类问题，看着吓人，根源可能就在一个Delay函数上。所以我的建议是——先易后难，先把能快速验证的项排除掉，再啃硬骨头。

嗯，PD协商失败带来的影响，不是一句「充不进电」能概括的。它贯穿供电、系统运行、外设交互三大维度，每个维度都有自己独特的「陷阱」。你把这些场景都记住了，下次碰到类似问题，心里就有谱了。