4. CC引脚与配置通道：CC1/CC2功能、上拉电阻、协议检测

好，我们正式开始第四章节。说实话，很多人学习USB Type-C，最容易卡住的地方就是这两个小小的CC引脚。我第一次调试Type-C项目时，也在这上面栽过跟头。CC线看似简单，但背后藏着整套角色识别、供电配置和协议协商的逻辑。搞懂了它，你就算入门了。

4.1 CC引脚到底是什么？

CC，全称是Configuration Channel，翻译过来叫“配置通道”。它不是普通的数据线，也不是电源线。它的任务就一个：告诉两边的设备，你是谁、我是谁，以及我们该怎么供电。

USB Type-C接口有24个引脚，其中CC1和CC2是最特殊的一对。它们有三大核心功能：

• 检测连接：判断插头是否插入，以及插入方向
• 识别角色：区分哪边是Source（供电方）、哪边是Sink（受电方）
• 协商供电：通过PD协议沟通电压和电流

为什么需要两个CC引脚？因为Type-C接口是正反可插的。你想想看，如果只有一根线，翻转后就没法用了。CC1和CC2的存在，让系统无论正插还是反插，都能找到正确的通路。

4.2 上拉电阻Rp和下拉电阻Rd

这才是CC引脚的灵魂。没有这些电阻，系统根本不知道对面接了个什么东西。

在Type-C规范里，Source端（比如充电器）的CC引脚上要接一个上拉电阻Rp，连接到VBUS。Sink端（比如手机）的CC引脚上要接一个下拉电阻Rd，连接到GND。

当两端通过CC线连接后，Source会检测CC引脚上的电压。这个电压值由Rp和Rd分压决定。不同的电压范围，对应不同的意思：

看到这个表，你可能会问：“为什么同样的电阻值，对应的电流能力不一样？” 嗯，这里要注意——规范里对不同的应用场景做了区分。10 kΩ这个值既可以是“未定义”，也可以是“1.5 A”，关键看Source端怎么实现。我个人的习惯是，在实际项目中统一用5.1 kΩ来支持3.0 A，这样兼容性最好。

4.3 协议检测与角色识别

好了，现在物理连接已经建立。接下来要做的事，就是让Source和Sink互相认出来。

Source会不断检测CC引脚上的电压。当没有设备插入时，CC引脚电压等于VBUS（因为Rp上拉）。一旦插入了Sink，Rd接地，电压会被拉低。Source通过测量这个电压，就能知道对面是个Sink。

反过来，Sink也会检测CC引脚上的电压。如果电压被拉高（因为Source的Rp），说明对面是个Source。这个过程叫作“角色检测”。

但事情没这么简单。Type-C还支持双角色端口（DRP），也就是说一个设备既能当Source，也能当Sink。我记得第一次做DRP设计时，忽略了切换时序，结果两个设备都以为自己是Source，谁也不供电——嗯，这就是典型的“死锁”场景。

为了避免这种情况，DRP设备会周期性地切换自己的角色：一段时间充当Source（拉高CC），一段时间充当Sink（拉低CC）。对方在检测到匹配的角色后，才会正式建立连接。

4.4 CC逻辑的完整流程

我们把这些步骤串起来，看一个完整的连接过程：

1. 物理连接：Type-C插头插入，CC1或CC2连通（取决于插入方向）
2. 电阻采样：Source检测CC引脚电压，Sink也检测CC引脚电压
3. 角色确定：根据电压值，确定哪边是Source、哪边是Sink
4. 能力声明：Source通过Rp的值，宣告自己能提供的电流级别
5. 协议启动：如果需要更高级的供电，双方会进入PD协议协商阶段

下面这张图，把上述逻辑画成了流程，方便你理解。

4.5 调试中常见的CC问题

讲到这里，我觉得有必要跟你聊聊实际调试中那些让人抓狂的CC问题。我自己踩过的坑，列举几个典型的：

• CC电压异常：正常情况下，Source端CC引脚电压应该在1.2V~1.8V之间（当连接Sink时）。如果测出来是0V，说明Rd没有正常拉低；如果是3.3V甚至更高，说明Sink端可能没接Rd。
• 角色无法切换：DRP设备如果频繁切换角色，可能是CC引脚上的噪声导致误判。我在项目中遇到过，最后是给CC线加了100 pF的小电容滤波，问题就解决了。
• PD协议不启动：有时CC电压正确，但就是不进PD。这种时候，先检查VBUS有没有电——因为PD协议需要VBUS作为参考。我曾经碰上一个方案，VBUS在连接瞬间掉电，导致PD握手超时。

4.6 小结

CC引脚是USB Type-C生态的“话务员”。它用最简单的电阻分压方式，解决了角色识别、连接检测和供电配置问题。理解CC的工作逻辑，是后续调试PD协议的基础。