做USB Type-C的PD快充调试，最怕的不是协议复杂，而是芯片选了一堆资料却不知道从哪下手。FUSB302这顆芯片在PD方案里几乎是绕不开的常客，网上聊硬件的帖子很多，但真正把“Linux下驱动怎么配、怎么调、遇到问题怎么查”串成一条完整流程的文章却不多。这篇就把我从原理图到内核、再到跑通PD协商的完整路径写出来，希望能帮正在和FUSB302较劲的人踩平几个坑。
我自己实际做过的项目里，FUSB302用在了拓展坞、快充板卡和嵌入式Type-C口上，几乎都是同一个套路：硬件上接好I2C和中断脚，Linux内核使能FUSB302驱动，设备树配好节点，再通过TCPM状态机去和充电器或者主设备做PD握手。这个流程听起来短，但中间涉及电平、中断极性、寄存器时序、状态机日志，任何一个细节不对就卡住好几天。这篇文章会从芯片本身的能力边界开始讲，再一步步落到引脚连接、内核配置、调试命令和问题排查，适合刚刚开始接触PD调试的嵌入式工程师，也适合那种硬件已经做好、但驱动调不通想找思路的同学。
1. 弄懂FUSB302，先弄懂PD快充的“打电话”机制
1.1 FUSB302到底是一颗什么芯片，为什么大家都用它做PD
FUSB302是安森美推出的一颗单芯片USB Type-C控制器，也是目前嵌入式Linux平台用得最多的TCPC（Type-C Port Controller）芯片之一。它内部集成了Type-C检测、BC1.2、PD物理层的BMC编解码、以及对CC1/CC2两条配置通道的控制逻辑，通过I2C接口和主控通信。这里的关键词是TCPC而不是TCPM——它在PD链路里负责的是“收发信使”的角色，真正的策略和状态机通常由主控芯片软件实现。
为什么大家都选它？首先是便宜，一个FUSB302的物料成本远低于完整的PD协议芯片；其次是灵活，它把PD物理层和状态机分离，你想在Linux内核里跑标准TCPM，还是想自己在RTOS上写一套策略，它都能配合。很多I2C慢速设备在PD场景下会卡在时序上，但FUSB302内部有独立的收发逻辑，BMC信号编解码不占主控中断，实测在几百kHz的I2C总线上跑PD3.0协商也没问题。
还有一个原因是封装小、外围电路简单。QFN一个小封装，除了去耦电容、I2C上拉、中断上拉和VBUS分压电阻，基本不用别的，硬件工程师画原理图时不用花太多心思。但这也带来了一个副作用：能用到的地方太多，反而让不少人是“照抄参考设计画完板子，却说不清每个引脚为什么这么接”，一旦调不通就只能干瞪眼。
1.2 在快充链路里FUSB302负责什么、不负责什么
要讲清楚驱动调试，得先分清楚职责边界。一个完整的PD快充端口，通常包含这么几部分：
- TCPM（Type-C Port Manager）：负责策略，比如检测到接入后决定自己是Source还是Sink、要发哪些能力包、怎么响应对方的请求。
- TCPC（Type-C Port Controller）：负责物理层，比如把TCPM的指令变成CC线上的BMC信号，同时把收到的信号解码成中断事件上报。
- Policy Engine：可以理解为TCPM内部的状态机，负责PD协议的协商、重试、超时处理。
- 电源部分：Power Switch / Path，真正控制VBUS通断、升压降压的部分。
FUSB302属于TCPC这一层。它不负责“到底要不要给对面供9V还是12V”，这个决策在Linux内核的tcpm.c里完成；但“把9V的请求包编码成BMC信号发到CC线上”，以及“收到Source Capabilities后触发中断通知主控去解析”，这些是FUSB302干的活。
明白这个边界之后，很多调试问题就好定位了。比如你发现PD协商一直不成功，就要先判断是FUSB302压根没收到包（物理层问题），还是收到了包但TCPM没有正确处理（策略层问题）。前者查硬件、查寄存器，后者开内核日志、查状态机。否则一上来就对着驱动代码死磕，很容易绕远路。
1.3 为什么Linux内核有现成的FUSB302驱动，你却还要调试
很多人会问：内核里不是自带drivers/usb/typec/fusb302/驱动吗？配置上之后插上就能用吧？实际情况远没那么简单。内核里的FUSB302驱动确实存在，而且质量不差，但它依赖几个前提：你的设备树节点完全正确、I2C通信正常、中断能正常触发、硬件上的上下拉配置和驱动预期一致。任何一个前提不满足，驱动要么probe失败，要么能加载但状态机异常。
另外，内核自带的FUSB302驱动是和TCPM框架深度绑定的，它不是一个独立可用的“PD库”，而是tcpm.c状态机的一个底层实现。真正负责PD协商逻辑的是drivers/usb/typec/tcpm/tcpm.c，FUSB302驱动只是向它提供注册回调、中断上报这些基础能力。所以“调试FUSB302驱动”本质上是在调试“TCPM + TCPC”这条链路，这也是为什么看日志的时候要同时关注fusb302和tcpm两层输出。
理解了这一层，你再看网上那些报错、日志、寄存器操作，就不会一头雾水了。接下来的硬件连接部分，就是所有调试的基础，电路上出了一个细微差异，后面软件上可能要排查好几天。
2. 硬件连接：不要以为照着参考设计画就完事了
2.1 引脚级拆解：每个关键引脚该接什么、为什么
FUSB302的引脚不多，但每一个在调试中都可能成为拦路虎。我把关键引脚按调试时踩坑概率从高到低列一遍。
INT_N中断引脚：这是FUSB302向主控汇报事件的“门铃”。它是开漏输出，低有效，使用时必须外接上拉电阻到VDD，通常4.7k到10k都可以，然后接到主控的一个GPIO上。这个GPIO在内核设备树里配置为中断，中断类型必须是电平触发（IRQ_TYPE_LEVEL_LOW），不能是边沿触发。原因后面调试部分会细说，这里先记住。
I2C引脚（SCL/SDA）：标准的I2C接口，需要上拉电阻，阻值一般取4.7k。如果主控的I2C电平域是1.8V，而FUSB302供电是3.3V，这里必须加电平转换或者选用支持1.8V电平域的应用电路，否则通信会偶发失败甚至烧毁引脚。很多项目把I2C挂在SoC自带I2C控制器上，此时要确认SoC这路I2C没有被固件或其它外设占用。
VBUS感测引脚：FUSB302需要感知VBUS上有没有电压，这直接决定它判断当前是自己供电还是被供电。VBUS可能高达20V，芯片这个引脚耐压有限，所以必须用电阻分压后送入。分压比例要根据芯片数据手册的输入电压范围设计，典型做法是用高阻值分压网络，让VBUS在5V时引脚电压落在0.4V左右的安全区间。有人图省事直接接主机3.3V逻辑电平去判断，结果VBUS被拉偏，SD和VBUS保护逻辑全乱。
CC1/CC2引脚：这两根线是所有PD通信的物理通道，接USB Type-C连接器的CC1/CC2即可。大多数参考设计会在中间加一个串联电阻或者滤波电容，实际上FUSB302内部已经集成了可配置的Rp/Rd电阻，外部不需要再去接上下拉，但ESD保护和合适的滤波是必须的。如果外部又加了上下拉，反而会和小芯片内部的电阻冲突，导致检测结果完全错误。
Reset引脚：FUSB302有复位脚，低有效，可以接一个简单的RC上电复位电路，或者由主控GPIO控制。调试初期强烈建议由GPIO控制复位，因为你可以在代码里通过操作GPIO让芯片重新初始化，省去断电重启的麻烦。一旦芯片因为I2C死锁或者寄存器配置异常进入错误状态，这就是最快的救命手段。
2.2 三个最容易画错的点：I2C地址、中断极性、VBUS检测
硬件画错的典型表现是：驱动加载不上、i2cdetect扫不到、probe报错。几个高频翻车点值得单独拿出来讲。
I2C地址是最容易翻车的。FUSB302的默认I2C地址是0x22，但这不是绝对的，芯片上有一个SEL引脚可以选择第二地址。SEL接低电平时地址是0x22，接高电平时地址会变化（具体地址表看数据手册）。如果你设计时为了走线方便把SEL悬空或者上下拉接反了，驱动里reg写0x22，i2cdetect扫到的却是0x23甚至其它地址，就会出现“芯片明明是好的，I2C却一直不通”的诡异现象。调试第一件事就用i2cdetect扫一下实际地址，别想当然。
中断极性问题在前面提过，这里再强调一次。FUSB302的INT_N是电平触发，不是脉冲触发。很多工程师习惯性地在设备树里用IRQ_TYPE_EDGE_FALLING，结果拔插Type-C线时中断只触发一次，后续的PD状态变化完全感知不到。原因是芯片内部的中断源很多，边沿触发会丢失“在一个低电平期间持续发生的多个事件”。正确的做法是IRQ_TYPE_LEVEL_LOW，然后在中断处理里反复读取中断寄存器，直到清完所有挂起事件。
VBUS检测分压电阻是第三个坑。FUSB302的VBUS感测引脚有一个检测阈值，分压后必须让5V时的电压落在阈值之上、20V时的电压不要超过引脚最大额定值。有些人为了省事直接用一个固定电阻接到地，结果VBUS电压高的时候直接触发过压保护，芯片报错不断；有些人则用1M+1M这种超大阻值分压，导致引脚输入阻抗太高，测量不稳定。实际设计时参考数据手册里的推荐分压网络，别自己从头算，除非你很清楚输入漏电流的影响。
2.3 电平域与PCB走线：一张表看完关键检查项
| 检查项 | 推荐值/做法 | 一项错会怎么样 |
|---|---|---|
| VDD电压 | 3.0V-3.6V，典型3.3V | 电压偏低时芯片不工作，i2cdetect扫不到 |
| I2C上拉 | 4.7k到10k | 上拉太小I2C拉不下去，太大通信慢且易受干扰 |
| I2C电平域 | 必须和主控匹配 | 不匹配会导致I2C通信不稳定，甚至损坏引脚 |
| INT_N上拉 | 4.7k到10k，开漏必需 | 不接上拉，中断引脚浮空，驱动永远收不到事件 |
| 中断类型 | IRQ_TYPE_LEVEL_LOW | 用边沿触发会丢事件，PD协商状态卡住 |
| VBUS分压 | 按数据手册推荐 | 阈值错误导致VBUS判断错误 |
| CC1/CC2 | 直接接连接器，外部不要重复上下拉 | 重复接地/上拉会导致Type-C状态识别错误 |
| Reset | RC复位或GPIO控制 | 无复位信号芯片可能起不来 |
| 去耦电容 | VDD引脚加0.1uF，靠近引脚 | 数字噪声大时寄存器读写偶发错误 |
PCB走线上，CC1/CC2作为差分信号对来做等长处理，虽然BMC波特率不高，但布线好的板子调试时干扰明显少。VBUS感测走线尽量短，避免引入噪声导致ADC判断抖动。我见过一块板子，其它都正常，就是VBUS分压电阻放在了远离芯片的位置，结果快充握手时偶发VBUS检测抖动，最后只能把电阻挪近。
3. 使能内核驱动：让芯片先“冒头”
3.1 内核Kconfig依赖：不多不少正好这几个
Linux内核从4.x开始就集成了FUSB302驱动，路径在drivers/usb/typec/fusb302/。驱动编译需要通过内核Kconfig打开，而且它依赖Type-C子系统。用menuconfig配置时可以按这个路径找：
Device Drivers -> USB support -> USB Type-C Support -> USB Type-C Port Controller Manager (tcpm.c) FUSB302 Type-C controller driver打开之后还有两个经常被忽略的依赖项：一个是CONFIG_USB_ROLE_SWITCH，另一个是CONFIG_POWER_SUPPLY。前者的作用是让TCPM能把Type-C口的角色切换通过标准的角色切换框架通知其它子系统，后者是为了把PD协商出来的电压电流暴露到power_supply类设备里。如果只开FUSB302而没开role switch，部分平台会出现驱动加载成功但状态机无法切换角色的问题；没开power_supply，你在/sys/class/power_supply下就看不到typec相关的电源信息，验证快充时少一个观察窗口。
另外，如果你的内核版本比较老，可能没有drivers/usb/typec这个目录，那需要先把内核升级到支持Type-C子系统的版本，或者考虑把drivers/usb/typec目录从新内核backport过来。FUSB302驱动依赖的tcpm基础设施比较多，backport并不是简单复制几个文件，涉及不少头文件和Kconfig依赖，预算允许的话直接升内核版本更省心。
3.2 设备树节点：一个能用的FUSB302节点长这样
设备树节点是驱动和硬件之间的“桥梁”。FUSB302挂在一路I2C上，所以要在对应的I2C总线节点下添加子节点。以我手上一块RK平台的板子为例，节点长这样：
&i2c2 { status = "okay"; clock-frequency = <400000>; fusb302@22 { compatible = "fcs,fusb302"; reg = <0x22>; interrupt-parent = <&gpio3>; interrupts = <13 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&fusb302_int_l>; fcs,port-type = "dual"; vbus-supply = <&vbus_5v>; status = "okay"; }; };reg = <0x22>对应芯片的I2C地址；compatible = "fcs,fusb302"是驱动匹配的关键字符串，不能写错；interrupt-parent和interrupts指定INT_N接在哪个GPIO、什么触发方式；fcs,port-type有source、sink、dual三个可选值，dual表示这个口既能当主机供电也能当设备受电，拓展坞和EVB板通常用dual。vbus-supply不是必须的，但如果你想让TCPM去控制VBUS的通断，比如在source模式下向外输出5V，就需要在驱动层面把VBUS控制节点关联起来。
这里特别提醒pinctrl那行，它是很多人容易漏掉的。FUSB302的INT_N接到了某个GPIO上，这个GPIO必须有正确的引脚复用配置，否则即使设备树里写了IRQ，实际GPIO还是被配置成普通输入或其它复用功能，中断压根触发不了。在板子调试阶段，可以把pinctrl-0先去掉，让GPIO保持默认状态，确认中断能触发后再加上pinctrl，这样能减少变量。
另外有些平台或者新版内核可能会在设备树里看到fcs,use-vbus-supply这种布尔属性，它控制驱动是否通过regulator框架去操作VBUS电源。如果你不需要内核去控制VBUS输出，直接不写就行；如果写了，但没有对应的regulator节点，驱动probe时就会因为找不到电源而失败。
3.3 驱动加载成功的标志：dmesg里该看到什么
配置好设备树、编好内核之后，把板子启动起来，第一时间看dmesg。驱动加载成功时，应该能看到类似这样的日志：
fbus302 2-0022: fusb302_probe: rebooted fbus302 2-0022: fusb302: 2.0.0 tcpm: registered port0 typec port0: registered不同内核版本打印的字段会有差异，但以下几个关键点必须在：
- I2C能匹配到设备，log里出现了2-0022这种“总线号-地址”的标识。
- 驱动成功向tcpm框架注册了一个port，log里能看到tcpm相关的输出。
- /sys/class/typec/目录下出现port0。
如果驱动probe失败，常见的报错包括：failed to read chip id、register tcpm port failed、failed to request irq等等。这些错误信息会把问题直接指向I2C通信、中断配置或设备树属性这三个方向，接下来就该进入调试环节了。
驱动加载成功只是第一步，它说明I2C和中断基本通了，但PD协议能不能正常走起来，还得继续往下看。这也是很多人卡住的地方：驱动加载没问题，但插上充电器就是不快充。别急，下一整个调试流程就是干这个的。
4. 驱动调试：从i2cdetect到PD报文协商
4.1 先确认I2C通信：i2cdetect和i2cget的现场用法
不管驱动日志说什么，第一步永远是先手动扫I2C总线。假设FUSB302挂在I2C总线2上，在板子串口里执行：
i2cdetect -y -r 2如果芯片正常上电、地址是0x22，输出里会看到：
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f ...看到0x22出现，说明I2C物理链路是好的。如果任何地址都扫不到，先检查供电和SEL引脚。我遇到过一块板子，原理图上SEL明明接了地，但贴片时焊错位了，结果芯片地址变成0x23，扫出来还以为挂了两颗芯片。
确认地址后，可以顺手读一下FUSB302的芯片ID寄存器，验证通信不只是有ACK而是能正确返回数据。FUSB302的寄存器0x01是Device ID，用i2cget直接读：
i2cget -f -y 2 0x22 0x01正常情况下会输出一个非0x00的字节。这个字节的具体值和芯片丝印批次有关，不必死记，重点是非0x00、且不会每次读都不一样。如果读到0xff，说明I2C应答了但内部没起来，大概率是芯片没解除复位；如果每次读都变化，可能电平域不对或者总线有干扰。
4.2 中断与插拔事件：为什么用LEVEL_LOW而不是沿触发
I2C通了之后，下一步验证中断链路。最直接的办法是插拔Type-C线，看dmesg里有没有中断回调打印。FUSB302驱动在中断处理里会打印一些事件信息，如果看到类似fusb302_irq: ...的输出，说明中断链路通了。
中断这一个环节值得多说几句。很多板子驱动加载正常、I2C通信正常，但一插线就卡死，或者插拔10次有3次没反应，八成都是中断触发方式配错了。FUSB302的INT_N脚是电平低有效，芯片内部有一个中断闩锁机制：只要任何一个中断事件没有处理，INT_N就会一直保持低电平。如果你在设备树里配了IRQ_TYPE_EDGE_FALLING（边沿触发），那么第一次中断发生时内核会收到一个下降沿，进入处理函数，但如果还有事件没有全部读走，INT_N仍然低电平，第二次新事件到来时没有新的下降沿，内核根本不会收到新中断，PD协商自然就“卡死”了。
正确做法是配置成IRQ_TYPE_LEVEL_LOW（电平触发），同时驱动程序的中断处理函数要把所有挂起的中断状态位一次性读干净。FUSB302的中断寄存器有多个，每个对应不同的事件源，处理完一个还要检查下一个，直到状态寄存器的挂起位全部清零。这也是为什么调试时别在interrupts里写IRQ_TYPE_NONE或者EDGE，严格遵守数据手册的低电平中断请求。
如果你没有改设备树的条件，还有一个折中办法：在驱动处理里用while循环反复读取中断状态，直到中断状态为零再退出。但这只适合验证阶段，真正量产时还是要把设备树配对。实测下来，把边沿改成电平触发，能解决80%以上的“插拔偶尔失灵”问题。
4.3 打开TCPM状态机日志：PD协商不再是黑盒
当驱动加载、中断链路都正常之后，PD协商是否成功才是最终目的。Linux内核里FUSB302驱动本身打印不多，真正的状态机日志在tcpm.c里。默认编译时这些日志被pr_debug隐藏了，需要用dynamic debug打开。
打开方法是在串口执行：
echo 'file drivers/usb/typec/tcpm/tcpm.c +p' > /sys/kernel/debug/dynamic_debug/control打开之后，插入一个PD充电器，dmesg里就能看到大量状态机切换日志。典型的输出长这样：
tcpm: state change SRC_UNATTACHED -> SRC_ATTACH_WAIT tcpm: state change SRC_ATTACH_WAIT -> SRC_ATTACHED tcpm: state change SRC_ATTACHED -> SRC_SEND_CAPABILITIES tcpm: PD RX, header: 0x2a1e: ... tcpm: state change SRC_READY -> SRC_TRANSITION_SUPPLY tcpm: state change SRC_READY -> SRC_READY这些日志是PD调试的宝藏。你不需要一开始就通读整个状态机，先关注几个关键状态名：...ATTACHED说明物理连接识别成功，SEND_CAPABILITIES说明芯片开始对外广播自己的能力，READY说明协商完成。如果日志一直卡在SEND_CAPABILITIES，说明包发出去了但对方没正确响应；如果日志根本不到ATTACHED，说明Type-C检测环节有问题，要看CC引脚和上下拉配置。
除了日志，还可以通过/sys/class/typec/port0/下的属性确认当前角色和状态。比如：
cat /sys/class/typec/port0/data_role cat /sys/class/typec/port0/power_role cat /sys/class/typec/port0/port_typepower_role会显示当前是Source还是Sink，data_role显示DFP还是UFP，这些信息和状态机日志能互相印证。如果power_role始终是Sink，但插的是供电设备，那说明方向检测错了；如果port_type是dual，也可以通过写这个属性来强制切换角色，调试时经常用：
echo source > /sys/class/typec/port0/port_type强制指定为source之后，FUSB302会主动发送Source Capabilities，方便你验证对外供电能力。
4.4 实际验证PD快充：看VBUS和PDO协商
到了这一步，你手里应该有一根能触发PD协商的Type-C线和一个支持PD的充电器，下面就是最直观的验证方式。
插入充电器后，打开动态日志，观察源码中的Source Capabilities输出。FUSB302作为Sink连接到一个PD充电器时，充电器会主动发送“我能提供哪些电压电流”的能力包。内核日志里能解析出PDO列表，可能长这样：
PDO: 5000mV 3000mA PDO: 9000mV 3000mA PDO: 12000mV 2500mA PDO: 20000mV 2000mA这只是充电器的能力，真正请求哪个电压是Sink端策略决定的。如果你没有额外的策略，默认的tcpm逻辑通常会请求第一个合适的PDO，大多数情况下是5V。想验证9V甚至12V协商，可能需要通过调整sink端策略或者debugfs接口强行指定。不同内核版本暴露的debugfs路径不一样，有些在/sys/kernel/debug/usb/typec/port0/下，有些没有开放，这个要根据内核源码确认。
更直接的快充验证手段是观察VBUS电压。用万用表量Type-C口的VBUS引脚，PD协商成功后电压会从5V跳到9V或12V。在Linux里也可以通过/sys/class/power_supply/看电池或电源适配器的电压实时值，如果板上有电量计的话。但最可靠还是示波器或万用表钩在VBUS上，因为USB功率传输都是通过电压跳变体现的，5V跳到9V、电流从1A升到3A，一眼就能确认。
如果协商一直停留在5V，常见原因有几种：线不支持PD（有些线只有USB2.0电阻，没有CC通信），充电器本身不支持高电压PDO，或者FUSB302的CC引脚外部电路破坏了通信。拿一根确定能用PD快充的线材替换测试，是最快的排查动作，不要一上来就怀疑芯片或驱动。
5. 常见问题与排查技巧实录
5.1 我踩过的坑：I2C不通、芯片没复位、中断风暴
这个章节记录几个我自己在实际项目中真实遇到的坑，每条都是花过时间才解决的。
第一个坑：I2C扫描不到设备，但硬件检查死活找不到问题。最后发现是FUSB302的Reset引脚悬空了。芯片上电后如果没有一个明确的复位高电平过程，内部逻辑可能一直停在复位状态，I2C虽然上拉有效但芯片不响应任何地址。解决办法是把Reset引脚接到GPIO控制，驱动probe前拉一下复位，或者在上电后在用户态用命令操作GPIO复位：
echo 1 > /sys/class/gpio/gpioXXX/value # 先拉低 echo 0 > /sys/class/gpio/gpioXXX/value # 复位 echo 1 > /sys/class/gpio/gpioXXX/value # 解除复位第二个坑：中断风暴。现象是板子一插电，CPU占用率飙到100%，串口被刷屏，日志里全是中断触发信息。排查发现设备树里中断类型配成了IRQ_TYPE_EDGE_BOTH，而FUSB302的INT_N是低电平触发，只要芯片认为有事件挂起，INT_N就一直为低，边沿双沿触发在电平为低时反复产生边沿中断，造成嵌套风暴。改成IRQ_TYPE_LEVEL_LOW后立刻安静下来。这个坑提醒我：不是所有“有中断”都是好事，中断类型必须和芯片设计匹配。
第三个坑：驱动报fusb302: failed to read chip id。这是I2C地址没对齐的典型现象，芯片应答了I2C探测，但驱动读Device ID寄存器时发现值不对。最后查清是板子上I2C地址通过SEL引脚选到了0x23，而设备树里写的是0x22，导致驱动虽然probe到了设备，但读取寄存器时访问的其实是一个不存在的地址。把设备树的reg改成0x23后正常。
5.2 排查流程速查：从现象到根因
实际调试中，问题往往不是单一原因，而是一串因果链。我习惯按下面这个顺序排查，能省掉很多无头苍蝇式的尝试：
- I2C能不能扫到？扫不到先查供电、Reset、SEL地址、I2C上拉、电平域。
- Device ID能不能读对？读不对说明I2C有应答但芯片内部异常，重启并查复位时序。
- 驱动probe是否成功？不成功看dmesg报错，绝大多数指向中断配置或设备树属性。
- 插拔线时有没有中断日志？没有中断日志就查INT_N引脚电平、上拉和GPIO复用。
- 状态机是否到达READY？卡在某个状态就通过tcpm日志分析卡点。
- VBUS电压有没有变化？没变化是PD协商没成功，回查线材和PDO。
把这个流程走一遍，绝大多数问题能在半小时内定位到具体环节。怕的就是一上来就到处打补丁，改了这个忘了那个，最后越调越乱。
| 现象 | 首选检查方向 | 次要检查方向 |
|---|---|---|
| i2cdetect扫不到 | 芯片供电、Reset | SEL地址、I2C上拉 |
| probe失败 read chip id | I2C地址 | 复位时序 |
| 能probe但插线无反应 | 中断触发方式 | GPIO pinctrl配置 |
| 插线有中断但状态机卡住 | tcpm状态机日志 | CC线通信质量 |
| 协商成功但VBUS不跳变 | 电源通路设计 | 线材/充电器能力 |
| 频繁插拔偶发失灵 | INT_N电平触发 | 中断挂起未清 |
5.3 一些能提升效率的小建议
最后分享几个调试效率工具。很多人不知道内核里其实有现成的GPIO操作接口，在调试前可以用它来手动控制FUSB302的复位和中断引脚，验证硬件链路。更实用的一个技巧是把dynamic debug命令写进系统启动脚本里，这样每次启动时tcpm日志就自动打开，省去每次手敲。
此外，FUSB302的寄存器映射很规整。调试时如果怀疑芯片内部状态不对，可以通过i2ctransfer直接写FUSB302的SWITCHES寄存器，手动切换CC引脚通路，快速验证CC链路。但注意寄存器操作前后要谨慎，最好记录当前值再改，改完调回默认，否则容易留下隐藏故障。
内核日志里有几个关键词值得重点关注：state change代表状态机流转，PD RX表示收到对端消息，PD TX表示发送消息，Hard Reset表示PD硬复位。调试时我通常只看这几个关键词，过滤掉大量无关打印：
dmesg | grep -E "state change|PD RX|PD TX|Hard Reset"这几条过滤出来，整个协商过程一目了然，比从头到尾看几百行日志高效得多。
FUSB302做PD快充，本质上就是把Type-C的物理层交给一颗成熟小芯片，自己专注于策略和调试。硬件上处理好地址、中断、VBUS检测三个关键点，软件上按I2C -> 中断 -> 状态机 -> VBUS的路径一层层往上验证，整个流程其实并不神秘。调试这行做得久了就会发现，大部分难啃的问题都不是芯片或内核搞不定，而是某个基础环节的细节没对齐。希望这篇流程能帮你少走几段弯路，把宝贵的时间留给真正需要挑战的部分。
