用逻辑分析仪抓取USB PD协议波形：BMC解码与实战排查

前阵子调一块USB PD受电端方案插上充电器后电压纹丝不动一直稳在5V。用万用表量CC引脚电压正常拿示波器戳在CC线上也能看到一堆跳变但就是看不出协议层到底走到哪一步。折腾到后面才意识到这类问题光靠眼睛看波形根本没戏必须用逻辑分析仪把USB PD的BMC编码完整抓下来再用协议解码器一层层剥开。这篇文章就把我这次完整的排查过程写出来从工具选型、线材改造到BMC手工解码和自动解码一步一步说清楚。如果你平时在搞Type-C快充、电池管理、嵌入式电源方向或者只是好奇PD协议在物理链路上长什么样这篇都值得花几分钟看完。我会把抓取PD通信波形过程中那些不写在文档里的细节一并讲透包括为什么必须用逻辑分析仪、采样率怎么定、CC线怎么接、BMC怎么解以及我踩过的几个比较隐蔽的坑。1. USB PD协议的三层结构先弄清楚CC线上跑的是什么1.1 物理层BMC编码与300kHz波特率USB PD跟I2C、SPI这类简单协议最大的区别就是它不像I2C那样直接靠高低电平表达0和1而是先用BMC编码把数据位转换成一串带时钟信息的电平序列然后才输出到CC线上。BMC的全称是Bi-Phase Mark Coding翻译过来是“双相标记编码”。规则不复杂只有两条每个位周期开始的地方电平必然发生一次翻转这个翻转用来给接收端做时钟同步额外再看位周期中间有没有翻转没有翻转代表逻辑0有翻转代表逻辑1。为什么PD要设计成这样因为PD的通信是单线半双工而且两端并没有独立的时钟线。如果在长距离或高噪声环境下直接传原始TTL电平接收端不仅难以判断每个bit的边界还容易被干扰误判。BMC把时钟信息嵌入到数据信号本身接收端只要检测到每个位周期起始沿就能自我同步。USB PD 3.0和3.1规范里BMC的标称数据率是300kbps换算一下每个位周期大概是3.33微秒。这个速率不算高但BMC编码后的信号在物理链路上会带不少谐波成分所以逻辑分析仪采样率太低的话边沿细节全糊掉后面解码就是空中楼阁。1.2 协议层数据包的构成BMC只是物理层的编码方式真正承载PD语义的是一个完整的数据包结构。一个标准PD数据包从波形上看依次包含前导码、SOP、消息头、数据对象可选、CRC32、EOP。前导码是一串固定的交替位模式作用跟汽车启动前的热车一样先把两端时钟对齐。SOPStart of Packet是一组特殊的控制符号用于标识“包从这里开始”同时区分是SOP、SOP还是SOP——普通设备间通信用SOP线缆和调试用后两种。消息头则记录包类型、数据对象数量、消息ID、端口角色等关键信息。数据对象是消息的实际负载比如Source_Capabilities里那几条电压电流组合就是放在这里。CRC32覆盖从消息头到数据对象的所有内容接收端校验失败就丢弃这个包。这部分结构理解到位之后再看逻辑分析仪解出来的十六进制串就不会一头雾水。很多初学者看到一长串raw data就不知道该从哪切开实际上只要按这个包结构去切每一段都对应一个明确的字段。1.3 策略层Source和Sink怎么对话物理层和协议层搞明白之后最后还得知道PD的策略层在干什么——这也是日常调试中真正需要关心的东西。在PD通信里供电方叫Source用电方叫Sink。连接建立后Source会主动发送Source_Capabilities消息把自己的“供电能力清单”广播给Sink比如5V/3A、9V/3A、12V/2.25A这些PDOPower Data Object。Sink收到后比较一番挑一个最合适的PDO回一条Request消息。Source如果同意就返回Accept然后执行电压切换切换完成后再发一条PS_RDY通知Sink“电已经送到位了”。这整套对话都发生在CC线上而且每次协商都只有几毫秒到几十毫秒。平时我们用万用表只能量到静态电压根本看不到这些交互示波器存储深度又有限录完一次握手之后再去翻找也麻烦。这也是我推荐逻辑分析仪来做这件事的原因——它能长时间以高采样率录制并且配合协议解码器把整个对话自动还原出来。2. 逻辑分析仪的选型与抓取环境搭建2.1 为什么选逻辑分析仪而不是示波器很多人第一反应是“我有示波器为什么还要买逻辑分析仪”。我在这次调试之前也是这么想的但对比完两者的特点之后你会理解逻辑分析仪在协议分析场景下的不可替代性。示波器的核心优势是模拟信号的细节呈现能看出过冲、振铃、压摆率这些模拟特征。但USB PD协议包通常在毫秒级时间内就发完了示波器如果采样率拉满存储深度很快耗尽如果把采样率降低去换取时长又无法精确还原BMC边沿。而逻辑分析仪本身就是为数字协议分析的场景设计的采样深度大可以在20MHz采样率下连续录制几秒钟的数据足够完整记录整个PD协商过程。另外逻辑分析仪配合软件后能直接跑协议解码器把BMC编码、SOP识别、CRC校验都自动完成输出的直接是Source_Capabilities、Request这类可读消息。示波器要做到这一步要么手动解码累死要么得额外买昂贵的协议分析模块。2.2 采样率、通道数与阈值设置说完选型方向具体到参数怎么定。抓USB PD波形逻辑分析仪的采样率建议至少开到10MHz我更推荐直接用20MHz到25MHz。原因很简单BMC波特率标称300kbps一个位周期3.33微秒BMC位中间的翻转点是1.67微秒的位置。如果用10MHz采样一个位周期能采33个点用20MHz能采66个点。点越多解码器判断翻转沿就越稳误码率越低。通道数方面理论上USB PD只需要抓CC线这一根信号所以单通道逻辑分析仪也能用。但我建议至少买8通道的型号原因后面会讲——同时抓CC1、CC2、VBUS和GND能帮你快速定位信号到底走的是哪个引脚。还有一个经常被忽略的坑是逻辑分析仪的电平阈值。CC线空闲时的电平不一定是标准3.3V尤其在Source通过电阻上拉的场景下CC线电压可能落在0.4V到1.6V之间。如果分析仪的输入阈值默认设在1.65V甚至2.5V那整段BMC波形中不少边沿会被识别成毛刺解码自然失败。所以在开始抓取之前务必检查分析仪的阈值设置确认它有1.0V或更低档位可选并且选择与CC线静态电平匹配的档位。2.3 把CC信号引出来的实操方法工具准备好了接下来最关键的硬件问题就是怎么把CC信号接到逻辑分析仪上。Type-C接口里有CC1和CC2两个引脚公头上分别是A5和B5。平时我们用的Type-C线缆内部是做好了CC连接管理的不会把CC信号引到外面。想抓波形有几种做法第一种是买一个Type-C公头母座的转接板这类转接板通常已经把CC1、CC2、VBUS、GND等引脚以排针形式引出来了直接用杜邦线接上逻辑分析仪就行。我用的是这种方案最省事而且不用破坏原装线缆。第二种是手动改造一根Type-C线把公头外壳打开找到A5和B5引脚焊出两根细线来。这种方法适合手上没有转接板又急着用的情况但焊接时一定要确认引脚编号焊错位置抓不到信号还以为协议没跑。第三种是使用专门的PD诱骗器和协议分析工具。诱骗器能强制Source进入PD协商流程省去用真实设备的麻烦适合重复测试。连接时记得把分析仪的GND和Type-C的GND可靠地接在一起。逻辑分析仪全部依赖参考地来判断高低电平地线没接好或者接触不良波形边缘会带大量毛刺CRC校验十有八九过不了。3. 实战抓波形让PD协商在触发下一次完成3.1 软件配置与触发条件硬件接好之后打开PulseView或Saleae Logic。这两个软件我都实际用过PulseView配合sigrok支持大量国产逻辑分析仪开源免费而且自带USB PD协议解码器Saleae Logic的协议解码器做得也比较成熟但需要确认你的硬件版本支持。以PulseView为例连接设备后先设置采样率这里直接选20MHz。采集时长设置成50毫秒到100毫秒比较合适因为PD协商从连接建立到PS_RDY一般不会超过几十毫秒。太长浪费内存太短可能覆盖不到完整对话。触发条件这里有个经验如果你用的是质量较好的逻辑分析仪可以直接选上升沿触发在Sink插入的瞬间触发采集。如果分析仪支持带协议触发比如检测到特定的SOP前导码那就更理想能保证抓到的都是有效数据。不过入门级设备通常只有电平边沿触发也够用。3.2 触发一次协商过程配置好之后让系统处于“等待触发”状态然后插入充电器或者插入受电设备让PD协商在CC线上发生。实际操作中有一个细节需要注意如果设备已经连接完成之后再打开逻辑分析仪是来不及抓到协商过程的。因为PD的握手通常只在连接建立后的几十毫秒内发生一次之后CC线就安静下来了。正确做法是先让分析仪处于armed状态再去执行“插线”或者“上电”这个动作。我用诱骗器测试时习惯先把诱骗器调到固定请求9V/3A然后给Source上电。每次上电Source都会发起一轮Source_Capabilities广播触发逻辑分析仪开始录制稳定可靠。3.3 波形分段阅读前导、SOP、数据、CRC、EOP抓到波形之后先不要急着上解码器先用肉眼扫一遍波形的大致结构培养对BMC波形的直觉。把一个PD包在时间轴上放大你会看到最前面是一长串均匀翻转的方波这就是前导码。因为BMC编码保证每个位周期开始都有翻转所以前导在波形上看起来是非常规整的脉冲串。紧接着前导会看到稍有不同的码型组合对应SOP的K码。SOP之后则是消息头、数据对象和CRC32的数据区域。这一段在BMC波形上表现为密集的翻转和不翻转的组合如果数据段里有长的连续0可以看到某一段电平维持较长时间不跳变而连续1则表现为位周期中间多一次翻转。EOP是包的结尾标记之后CC线恢复空闲电平。一次完整的Source_Capabilities消息从开始到结束大概几百微秒用逻辑分析仪的缩放功能能轻松看清每个细节。4. BMC解码实战手工解析与自动解码4.1 手工从BMC波形恢复数据位这一节是全文的核心所以我尽量把过程拆细。先说怎么在不解码器的情况下用手工从波形里读出原始数据位。拿到一段BMC波形后第一步定位周期。USB PD标称300kbps位周期约3.33微秒但因为Source和Sink的时钟都有一定容差实际周期可能在3.0微秒到3.7微秒之间浮动。更可靠的做法是测量波形中连续翻转沿之间的距离来推算实际位周期。注意前导码部分是最理想的参考因为它按固定模式翻转量10个翻转周期取平均误差非常小。第二步按位周期把波形切开检查每段中间有没有额外翻转。BMC规则再复习一遍位周期开始必然翻转中间额外有翻转的是1中间没有翻转的是0。按照这个规则逐位读取把读出的0/1序列按行记下来。第三步把读出的位流再做4b/5b逆映射。PD物理层在BMC之上还有一层4b/5b编码目的是保证线路上有足够的跳变密度、维持DC平衡。这层编码会把每个4bit数据展开成5bit码字解码时刚好反向操作。这里要注意4b/5b的符号表在USB PD规范附录里是明确给出的手动查表时一定要用PD规范的表不要照搬以太网100BASE-X的表两者只有部分一致。第四步找到SOP边界。SOP对应的K码组合在码流里是唯一的标志找到它后面跟着的就是消息头和数据字段了。我在第一次手工解码时花了大概半小时才读完一个Source_Capabilities包。慢是慢但这个过程做完之后你对BMC和PD包结构的理解会彻底不一样——后面用解码器一键解出来结果你一眼就能看出它解的到底对不对。4.2 4b/5b符号表与SOP识别从读者反馈来看4b/5b这段是最容易卡住的。我再展开讲讲。4b/5b编码的思路很简单把原始数据流切分成每4bit一组16种组合然后映射成5bit码字。为什么要用5bit码字因为4bit只有16种组合5bit有32种组合多出来的空间可以专门定义一些特殊的控制码K码同时还能保证码字里不会出现过长的连续0或连续1。SOP就是这些特殊控制码的组合。USB PD规范里定义了SOP、SOP、SOP三种起始包标识分别用于普通通信、线缆通信和调试通信。它们用不同的K码序列来表示在BMC波形的世界里这些K码就是一组能让接收端明确辨认的“暗号”。实际手动解码时你只需要关心两件事一是在位流里找到SOP的K码序列确认包的起始位置二是确定SOP类型因为后面消息头的解析策略在不同SOP类型下可能有区别。我建议手工解析时先把整体位流按SOP切段把SOP之前的统统归为前导码不在数据范围里纠结。这能帮你省掉很多不必要的计算。4.3 消息头与数据对象解读SOP之后的部分才是真正表达PD业务语义的字段。消息头总共占16bit核心字段包括消息类型、数据对象数量、消息ID、端口角色和规范版本。消息类型决定了这条消息是什么。USB PD规范把消息分成控制消息和数据消息两大类。控制消息里常见的像Accept、Reject、PS_RDY、Get_Source_Cap数据消息里最常遇到的则是Source_Capabilities、Request、Sink_Capabilities。协议解码器通常已经把这些类型翻译成人话你直接在解码结果里看名称即可。数据对象数量记录这条消息里实际携带了多少个对象。对于Source_Capabilities来说它后面跟的就是PDO列表。每个PDO有32bit编码了电压、电流和供电类型固定供电、可变供电、PPS等。举个例子我在测试中经常看到的PDO格式大致是这样的bit31到bit30是供电类型bit29保留后面的位段分别表示电流、电压具体精度由规范里固定的标称电压/电流单位决定。换算规则简单但容易记混解码器输出里一般会直接标出mV和mA所以日常调试手动换算的机会很少。但如果你要写固件或者设计协议栈这部分就必须要吃透。4.4 PulseView和Saleae自动解码与结果核对手工解码关过了之后再上自动解码器你会发现效率不是翻倍而是翻了几十倍。PulseView中添加协议解码器时选择USB PD然后指定CC信号所在的通道软件就会自动完成BMC解码、4b/5b解码、SOP识别、CRC校验和数据字段提取。解码结果会叠加在波形上方双击还能展开每个字段的详细值。Saleae Logic的操作路径也差不多在协议解码器列表里选择USB Power Delivery同样指定通道和信号类型。两家解码器在遇到无法识别的码型时会标注错误这种错误标记本身也是排查信号质量问题的利器。自动解码跑完之后强烈建议找一个包跟第4.1节手工解码的结果做一次交叉核对。这一步不是为了较真而是验证你对BMC的理解是否到位。如果自动解码出的消息类型、PDO数值和你手工读出来的一致说明整个链路包括工具和信号的认知都没问题如果不一致先检查是不是SOP类型选择错了再看解码器设置的信号极性是否正确。5. 高频踩坑与完整排查链路5.1 抓不到波形从探针到触发的逐级排查把所有连接都接好点击运行结果满屏空白这是我在这个项目里遇到最多的情况。遇到这种问题别急着怀疑协议没跑按下面这个链路一级一级查。先确认CC线到底接对了没有。Type-C是有方向性的插入时CC1和CC2只有一根被选作通信通道。如果你的探针接的是另外一根那自然录不到任何信号。判断方法是把探针同时接到CC1和CC2两根线上分别用两个通道录制看哪个有波形。再确认触发条件是否合理。如果你用的是上升沿触发要确认CC线空闲时的电平确实低于分析仪的阈值否则上升沿永远不会被识别。这是在低电压场景下比较容易踩的一个大坑CC线空闲电压本来就只有零点几伏分析仪的阈值设得比空闲电平还高根本等不到上升沿。最后确认设备是不是真的发起了PD通信。很多Type-C设备在没有供电需求时不会主动发起通信只有先确认CC上出现了标准的BMC脉冲才能说明协议确实在跑。5.2 解码乱码与误码阈值、采样率与地线波形明明抓到了但自动解码器输出的内容乱码或者CRC校验经常失败也是新手几乎必遇的问题。这类问题通常有三个诱因。第一个是采样率不够。如果你用的是10MHz以下的采样率BMC边沿的判定会变得很不稳定尤其是信号本身压摆率一般的情况下解码器可能把一个翻转误判成两个甚至漏掉一个。建议直接把采样率拉高到25MHz再抓一次对比一下解码结果。第二个是阈值设置太靠近信号电平。如果CC线的静态电平在阈值附近晃叠加一点噪声就会产生虚假边沿。解决办法是选一个低于静态电平但高于噪声的阈值档必要时用逻辑分析仪自带的电平窗口功能观察信号在阈值附近的稳定程度。第三个也是最容易被忽视的——地线接触不良。逻辑分析仪的地线和被测系统共地是数字信号正确解读的前提地线虚接时信号本身没问题但分析仪采到的波形全是毛刺导致后续解码彻底崩坏。有一次我反反复复试了很多次都报CRC错最后发现是杜邦线松了一点点重新插牢之后一切正常。5.3 CRC校验失败的信号质量问题如果你的解码器能稳定识别SOP和消息头但每条消息的CRC32都是大红叉这时候基本可以判断是信号层面出了问题而不是协议包本身有问题。CRC32是覆盖消息头和所有数据对象的校验和任何一位翻转都会导致校验失败。数据包能解出结构但校验不过说明抓到的码流里大概率存在位错误。常见原因包括探针地线太长导致的环路干扰、Type-C转接板上的信号反射以及逻辑分析仪输入带宽不足导致的高频分量丢失。处理办法按成本从低到高排列先换一根短的地线尽量让地线探针直接接触Type-C母座的地再把采样率拉满同时减小采集时长减少无关数据对内存和带宽的占用如果还不奏效考虑在CC线上串联一个几百欧的电阻减小阻抗失配造成的反射。这三板斧下来绝大多数CRC错误都能解决。5.4 延伸这套方法论在I2C、SPI分析中同样适用聊完USB PD最后说个更通用的经验。逻辑分析仪这东西本质上帮你做的是同一件事把物理层的电压变化还原成协议层的数据流。I2C需要关注SCL和SDA两根线的时序关系SPI需要关注时钟极性和相位UART需要关注波特率和起始位USB PD需要关注BMC编码和4b/5b映射——虽然协议细节千差万别但分析思路完全一致。你先弄清楚这个协议的物理层怎么编码、包结构怎么定义、时序约束是什么再反过来用逻辑分析仪去抓对应的信号配合协议解码器验证自己的理解。我在这次PD调试之后再用逻辑分析仪分析I2C和SPI时明显从容了很多因为底层方法论是通的。最开始抓PD波形没有头绪一是因为BMC编码比普通电平编码复杂一些二是对协议包结构不熟一旦这两个问题都补上了逻辑分析仪就变成了透视CC线的眼睛。