企业官网建设流程全解析

做MTK平台驱动或者充电方案的朋友，应该都有这种体会：Type-C接口看着简单，实际调起来是硬件、协议、系统三层问题搅在一起。尤其是MTK6769这种出货量很大的中端平台，搭配Android 15新内核后，充电链路里任何一个环节不对，表现出来就是“不充电”“慢充”“充电断断续续”，甚至还会把DP显示功能一起带崩。这篇东西我不打算从原理图开始一笔一笔教你画板子，而是基于我在MTK6769平台上实际调试Type-C充电的经历，把硬件管脚、PD协议协商、Android 15系统框架这几层串起来讲清楚。里面涉及的寄存器地址、日志关键字、排查顺序，都是可以直接拿去用的。

1. 整体链路拆解：从Type-C物理管脚到Android 15充电框架

1.1 Type-C接口硬件管脚逐一说明

先把Type-C接口的管脚理清楚，这是排查一切问题的基础。Type-C插座有24个针脚，但跟充电相关的其实就那么几个：VBUS、GND、CC1、CC2、DP、DN，还有SBU1/SBU2和VCONN。

VBUS是充电主通道，正常PD快充时电压可以到5V、9V、15V甚至20V，电流可以到3A、5A。GND就是地，但要注意Type-C是双面可插的，所以GND有四根针脚，布局上要保证大电流回流的过孔数量足够，否则充电电流一大，地弹噪声能把CC检测直接干扰掉。

CC1和CC2是关键。这两个管脚承担了三件事：检测正反插、协商电流能力、以及作为PD协议通信的通道。Android 15的Type-C驱动里，CC检测结果直接决定端口角色（Source/Sink/DRP）。如果CC管脚上拉的电阻不对，最常见的现象就是插上充电器完全没反应，或者只能以USB 2.0的500mA电流充电。

DP和DN是USB数据线，在充电场景里它们承担的是BC1.2握手时的数据通信。快充协议（QC、PE、PD）很多都需要在DP/DN上做电压信号交互。比如QC2.0的经典握手，就是D+上拉0.6V、D-上拉3.3V这样的组合。所以硬件设计上，DP/DN这两根线到充电IC的距离太远或者串了磁珠过大，都会导致协议握手不稳定。

SBU1/SBU2在充电场景里用得不多，但在USB PD的Alternate Mode（比如DP over Type-C）里，它们就是视频数据的传输通道。这也是为什么有时候充电和投屏会互相干扰，调试时要在dts里同时关注Type-C的pinmux配置。

1.2 MTK6769充电硬件架构

MTK6769平台的充电硬件，核心是充电IC。常见搭配是MT6370或者类似型号的PMIC一体芯片。MT6370集成了BC1.2检测、PD物理层（PHY）、充电泵和线性充电器，这颗芯片在MTK平台上的地位就相当于“充电大脑”。

从MTK6769的参考设计来看，充电通路大概是这样的：Type-C接口的VBUS先进到MT6370的VBUS管脚，CC1/CC2连接到MT6370的CC管脚，DP/DN连接到MT6370的USB D+/D-管脚，MT6370再通过I2C总线和中断（IRQ）跟主控芯片MT6769通信。同时，那颗专门做PD协议控制的芯片（比如MT6370内部的PD引擎）会解析从CC线路上收到的PD消息，然后控制Charge Pump进行电压转换，最后输出给电池充电。

这个架构的关键点在于：硬件上要区分VBUS通路上的“直充”和“充电泵充电”。直充就是VBUS直接通过充电IC给电池，适用于5V/2A这类普通充电；充电泵充电则是通过电荷泵把输入电压减半，比如20V输入变成10V电池电压，电流翻倍，实现大功率快充。MTK平台的充电IC在dts里都有对应的节点配置，比如mt6370_charger、mt6370_pd这些，错误配置会导致快充协商失败，自动回退到慢充。

1.3 Android 15系统侧充电框架变化

Android 15在Type-C这块最显著的变化，是把Type-C状态管理和充电策略进一步统一到了Type-C内核框架（Type-C Kernel Framework）里。你可以理解成：系统里有个“Type-C管家”，所有跟USB端口有关的事情，都先过它这一层。

在Android 15里，这个框架由几个核心部分组成：typec类设备节点、typec_mux和typec_port驱动、USB Power Delivery策略引擎，以及上层的TypeCManager系统服务。MTK平台在此基础上，还会加上自己的mtk_charger和mtk_pd适配层。调试的时候，你会经常在log里看到typec相关的标签，比如type_c、tcpc、tcpm、pd policy这些。

Android 15还有一个重要的变化：对USB音频和投屏（DisplayPort Alternate Mode）的兼容性要求更高了。这就是为什么很多人在Android 15上遇到过“插上Type-C耳机没声音”“Type-C转HDMI无法投屏”的问题，其实根因往往不在音频或显示驱动，而在Type-C的状态机切换时序。充电状态和Alt Mode切换要是互相抢占，就会出现异常。

2. PD协议充电实战：从消息交互到策略协商

2.1 一文看懂PD与QC协议的核心区别

说到PD协议，就不得不提QC协议，因为很多人在调MTK6769充电时会发现，同一个充电器有时候走PD，有时候走QC，有时候走PE（联发科自己的协议）。这三种协议的本质区别，我尽量用大白话讲清楚。

QC（Quick Charge）是高通的私有协议。它的特点是利用USB的DP/DN数据线发送不同电压信号来“告诉”充电器输出电压等级。QC2.0支持5V/9V/12V/20V档位，QC3.0则用0.2V步进精细调节。它最大的问题是缺乏双向握手机制，充电器不知道设备的真实需求，只能按照预设档位来。所以QC充电的安全性、灵活性都不如PD。

PD（Power Delivery）是USB-IF组织定义的标准协议。它最大的特点是通过CC线进行双向数字通信。充电器和设备可以用结构化消息互相协商电压、电流、甚至供电方向（谁给谁充电）。PD 3.0引入的PPS（可编程电源）让电压电流可以精细调节，这是目前安卓手机实现“百瓦级快充”的底层基础。对我们做调试的人来说，PD最大的好处是“可以通过协议日志看到协商过程”，这是QC完全没有的。

PE（Pump Express）是联发科自己的快充协议。它在老款MTK平台上很常见，原理上跟QC类似，也是通过VBUS电压变化来通信，但在实现细节上和QC不兼容。MTK6769平台出厂默认是支持PE的，如果充电器是QC或者PD的，驱动里会进行协议优先级判断。一般来说，优先级从高到低是：PD > PE > QC > BC1.2 > 标准USB。

2.2 PD协商的完整交互过程

PD协商看起来复杂，核心流程其实就三步：探测、能力协商、进入具体档位。

第一步是探测。插上充电器后，MTK6769的TCPC（Type-C Port Controller）驱动会检测CC管脚上的电压状态（Rd/Rp），判断插入方向和端口角色。这个阶段日志里会出现类似cc=1 attach的信息。如果CC检测失败，后续所有流程都不会执行。

第二步是能力协商（Source Capability，简称SrcCap）。充电器会通过CC线广播自己支持的电压电流档位，比如"5V/3A、9V/3A、12V/2.25A、15V/3A、20V/3A"。设备端收到后，会基于当前电池电压、温升状态、充电IC能力，选一个最合适的档位，然后发送Request消息。日志里找PD src cap和pd request就能看到完整过程。

第三步是进入具体档位。充电器收到Request后，会回复Accept和PS_RDY消息，然后把VBUS调整到协商好的电压。系统检测到VBUS稳定后，打开充电通路，开始大功率充电。这一步MTK平台的日志关键字是pd ready或者vbus stable。

如果在这三步中任何一步消息丢失、校验失败或者超时，PD协议就会进入错误重试机制，或者直接回退到安全模式（默认5V/2A或5V/3A）。所以在排查“达不到预期功率”的问题时，第一步不是怀疑充电IC功率不够，而是去kernel log里看PD协商停在哪一步。

2.3 关键参数计算：档位选择与功率分配

PD协商里的档位选择，不是简单选最大功率档位。下面是我在MTK6769上常用的计算逻辑。

先看电流档位。Type-C的电流能力由CC管脚上的Rp电阻决定，默认是三种：USB默认（500mA/900mA）、1.5A、3A。这个叫Current Advertisement。即便设备支持PD协议，在CC没有被正确识别之前，系统最开始的输入电流上限还是按照这个电阻值来的。很多用户遇到的“插上电脑只充电不读数据”，原因之一就是CC上Rp电阻焊错或者配置不对。

再看功率分配。假设充电器广播了5V/3A、9V/3A、12V/2.25A三档。MTK6769的充电策略会结合电池电压、充电阶段来做选择。比如电池电压3.8V时，如果选5V/3A，充电IC的输入功率是15W，效率85%，实际到电池的功率约12.75W；如果选9V/3A，输入功率27W，经过Charge Pump降压效率90%，实际到电池约24.3W。显然9V档位充电更快。但如果电池电压已经4.4V接近满电，加大电压档位没有意义，反而增加发热，此时策略会选择低电压档位充电。

最后是PDO优先级。Android 15的USB PD策略引擎里有一个sink_pdo数组，里面写明了设备在不同状态下偏好的PDO顺序。比如亮屏时为了降低发热，可能偏向9V而不是15V；息屏时才允许15V甚至20V。这个偏好顺序写在pd_policy_manager驱动里，是可以按产品需求改的。

3. 实操环节：在MTK6769 Android 15环境下抓日志与定位充电异常

3.1 开启调试开关的正确方式

MTK6769 Android 15系统默认的充电日志级别比较低，很多PD协商细节看不到。第一步是开log。

确保内核打开了以下配置：

CONFIG_TYPEC=y CONFIG_TYPEC_TCPM=y CONFIG_TYPEC_MT6370=y CONFIG_USB_PD_POLICY=y

然后在kernel cmdline里加上调试参数，或者直接通过sysfs节点动态调整日志级别：

# 查看type-c端口状态 cat /sys/class/typec/port0/port_type cat /sys/class/typec/port0/power_role cat /sys/class/typec/port0/data_role # 调整tcpc驱动日志级别 echo 0x1f > /sys/module/tcpc/parameters/tcpc_log_level

MTK平台还有一个专门抓充电log的入口，就是MTKLogger的充电log模块，勾选charger、pd、tcpc这几项，就能把充电相关日志导出来。说实话，MTKLogger里勾选完导出的log，比你在串口看kernel log还要全，因为它会把I2C读写寄存器的记录都打出来。

3.2 常见充电异常与排查顺序

先列一个排查表格，是我在实际调试中反复用到的：

排查顺序我强烈建议固定为：先看CC物理层，再看BC1.2结果，最后才看PD协议。很多人一上来就抓PD包分析，结果发现PD包根本没开始，浪费大量时间。

3.3 实战案例：PD协商中途断链

说一个我印象很深的案例。某款基于MTK6769的设备，用某品牌65W PD充电器时，充电功率只能在18W左右徘徊，较难冲到更高的功率档位。从用户角度看就是“快充不够快”。

抓了日志后，发现PD协商其实很顺利，已经进入了9V/3A档位，但过了一秒钟左右，系统突然回退到了5V。进一步看，是vbus safe timeout触发了保护。原因很快查明：这台设备的VBUS电容容量偏小，在负载切换瞬间VBUS电压跌落超过了PD规范允许的范围，充电器检测到异常后主动回退档位。这不是协议问题，也不是软件bug，是硬件设计裕量不足。

解决方法是调整内核里的VBUS稳定检测窗口，把vbus_ovp和vbus_safe的阈值稍微放宽，同时在dts里把充电IC的vbus_ovlo配置从默认值调整到更合理的范围。硬件上也建议在原设计基础上增加一个22uF的陶瓷电容并靠近Type-C座子放置。这个问题也说明，PD协议链路稳定性的最终决定因素，常常在硬件布局和寄生参数上。

4. 硬件设计与dts配置要点

4.1 MTK6769 Type-C接口的PCB设计要点

硬件设计这块，我提几个容易踩坑的地方。

CC1/CC2线上必须加上ESD保护器件，但要注意ESD器件的寄生电容不要超过10pF。否则PD协议通信时，CC线上的信号上升沿会被拖慢，轻则协商速度变慢，重则直接通信失败。很多“特定充电器不兼容”的问题，最后查出来就是ESD管结电容太大。

VBUS通路上的低ESR陶瓷电容不能省。Type-C接入瞬间会有一个浪涌电流，如果VBUS电容不够，电压跌落会被协议芯片误判为供电能力不足。MTK6769参考设计上在VBUS每根针脚附近各放了一颗22uF/25V的电容，这个不要省。

DP/DN线的走线建议做包地处理。BC1.2握手依赖D+/D-上的电压信号，如果这两根线受到开关电源的噪声干扰，协议握手就会时好时坏。实测过，D+/D-走线附近有电感的情况下，QC握手成功率从98%降到了75%左右。所以Layout时务必让这两根差分线远离电感、Buck开关节点这些干扰源。

4.2 dts关键配置项说明

MTK6769在Android 15下的充电dts配置，重点看几个节点：

&mt6370_pd { status = "okay"; pd_sink_pdo_size = <3>; pd_sink_pdo = <PDO_FIXED_5V_3A>, <PDO_FIXED_9V_3A>, <PDO_FIXED_15V_3A>; source_pdo_size = <2>; source_pdo = <PDO_FIXED_5V_1A>, <PDO_FIXED_5V_2A>; }; &mt6370_chg { status = "okay"; charge_current = <2000000>; /* 2A default charging */ termination_voltage = <4450000>; /* 4.45V cut-off */ enable_te = <1>; enable_pe_plus = <1>; };

pd_sink_pdo这个数组定义了设备端“愿意接受”的PDO列表。如果你不想让设备在亮屏时进入15V档位，可以调整这个数组，或者通过策略引擎动态过滤。enable_pe_plus是开启联发科PE+协议的开关，如果产品只面向PD充电器，也可以关掉。

还要注意typec_mux相关的配置。Android 15对多路复用器的支持更完善了，/sys/class/typec/port0/mux节点在调试Alt Mode投屏、USB数据切换时非常有用。如果出现“插上Type-C投屏，然后充电状态变成USB慢充”的情况，优先看mux状态有没有被正确切到DisplayPort模式。

4.3 充电策略与温升控制

MTK6769平台的充电策略在mtk_charger驱动里有几个阈值节点：thermal_throttle、wpc throttling、pe+ warm limit。这几个阈值直接影响PD协商的档位选择。

比如说，设备温度到了45°C，系统会通过thermal框架通知mtk_charger降低允许输入电流。这个降低的动作，在PD协议里就是对充电器重新发起Request消息，换成低电流档位。如果你在测试时发现充电功率突然跳水，先看温度曲线是不是触发了降载。

我自己实际调过一台因为温升误判导致充电功率受限的设备。根因是NTC热敏电阻选择不当，位置离充电IC太近，充电IC局部发热导致NTC上报温度直接冲上50°C，系统误以为整机过热，果断降流。后面把NTC挪到了靠近电池的位置，问题解决。温升控制相关的参数调优，一定不能只看软件日志，要结合整机的热仿真和实测数据来定。

5. 常见问题速查：给直接抄作业的人

5.1 充电慢的排查清单

充电慢是最常见的Type-C问题之一，我按优先级整理了排查顺序：

1. 确认CC检测是否attach成功。日志里要找cc attach或者typec attach，如果反复attach/detach，就是接触不良或CC线受干扰。
2. 确认BC1.2检测结果。日志里bc12相关字段显示的是SDP还是CDP还是DCP。如果是SDP，证明没握手成功，充电电流会被限制到500mA。
3. 确认PD版本协商结果。pd version是3.0还是2.0，如果是2.0，部分PPS功能用不上。
4. 确认策略引擎有没有限制电流。看mtk_charger日志里的ibat_current和thermal_limit，如果电流限制比PD协商到的最大电流低，就是软件策略在起作用。
5. 确认充电线质量。PD充电线内部的E-Marker芯片如果坏了，也会导致协商档位受限。这个在日志里会有emarker not found之类提示。别看这步不起眼，我在实际项目里遇到至少三次“同一个充电器同一个手机，换条线功率就翻倍”的情况，根子就在线上。

5.2 Type-C接口插拔无反应

插上Type-C充电器后，手机完全没反应，连充电图标都没有。这种问题几乎可以锁定在CC检测链路。

先从硬件查CC1/CC2的对地电阻。Type-C规范里，设备端的CC对地需要接Rd（5.1kΩ），如果有两个CC都要接。万用表量一下，如果阻值差很多，说明焊接问题或者ESD损坏。

然后是系统层面检查。在Android 15的/sys/class/typec/port0/下，看port_type节点是不是dual-role。如果被配置成了host-only或者device-only，也会导致插件方向识别异常。这个在调试早期容易忽略。

最后检查dts里tcpc的gpio中断配置。MT6370的CC状态变化是通过IRQ上报给CPU的，如果中断GPIO复用被别的驱动占了，插拔事件就完全丢失。在dts里确认interrupt-parent和interrupts字段与硬件实际连接一致。

5.3 Android 15无法投屏的问题定位思路

这个属于充电以外的“并发症”，但确实是MTK6769在Android 15上经常出问题的点，我附带着讲一下。

现象是：Type-C转HDMI线插上，电视无信号，但充电正常。优先确认Alt Mode有没有进入。日志里找mode enter、displayport alt mode关键词。如果根本没进入，看两个点：一是线材是否支持DP Alt Mode，很多便宜的Type-C转HDMI线只支持充电，不支持视频；二是CC协议协商阶段有没有被充电流程打断。

如果充电和视频同时需要工作，TCPM驱动会做状态仲裁，这套逻辑在Android 15上更严格了。遇到“先充电再插视频线没反应”的案例，试着插拔顺序换成“先插视频线再插充电器”，如果能出画面，就说明是状态机切换顺序的问题，需要改typec_mux驱动的切换时序。

另外一个很隐蔽的问题是DP的lane配置和USB数据冲突。DisplayPort在Type-C上可以跑2 lane或4 lane，如果跑2 lane，另外2 lane保留给USB3.0数据。MTK6769在遇到非标准转接头时，偶尔会把lane数判错，导致显示花屏或黑屏。日志里看dp lane字段，确认是2还是4，如果不对，需要在转接头固件或者驱动里加固定的lane配置。

6. 实操心得与工具推荐

6.1 一款好用的PD协议分析仪

搞PD调试，软件日志虽然能看消息内容，但物理层信号质量、时序细节还是得靠协议分析仪。市面上常见的有一款支持PD3.1的Type-C协议分析仪，可以抓取CC线上的原始bit流，直接解析出消息头、消息体、CRC是否正确。我用它排查过一个“充电器再插一次才能快充”的怪问题，最后发现是设备发出的Request消息CRC连续三次错误，充电器端回NACK后进入重试，重试又因为软件状态没复位而失败。

没有协议分析仪也不要紧，可以用USB转I2C工具直接去读MT6370的寄存器，把PD状态机的内部状态读出来。比如0x1F寄存器里存有当前PD状态机的状态码，对照数据手册就能知道卡在哪一步。这个方法是“穷人版协议分析”，但胜在可以直接跑大规模复现测试。

6.2 日志分析技巧

MTK平台的充电日志量很大，一抓一大把，别盯着屏幕看。我的习惯是先用关键字过滤，再逐层深入。第一层是Type-C状态机相关，搜tcpc、typec attach、cc change，确认物理连接没问题。第二层是PD协商相关，搜src cap、pd request、PS_RDY，确认协议消息收发完整。第三层是充电状态相关，搜mtk_charger、vbus、ibat，确认实际充电参数跟协商结果匹配。

有一次排查一个“时而快充时而慢充”的随机问题，就是靠批量搜cc change日志，发现CC管脚状态在一秒内抖动了十几次，锁定了问题在于Type-C座子卡扣松动导致接触不良。这在实际产品返修中也很常见，座子夹持力不够，插上充电器稍微一晃就断链。

6.3 兼容性测试的几条经验

最后分享几条我踩过不少坑后才形成的测试经验。

第一，PD充电器兼容性测试，至少要覆盖五个档次的充电器：原装充电器、老款QC充电器、纯PD 3.0充电器、PD PPS充电器、电脑Type-C口。每一类都要测插拔、热插拔、满电转态、低电开充这几个场景。

第二，测试线材至少要准备三根：一根E-Marker全功能线，一根普通充电线，一根劣质线（故意让信号质量差的）。劣质线材往往能暴露硬件裕量不足的问题。之前有个项目就是因为用优质线材时一切正常，出货后大量用户反馈“特定品牌充电器不兼容”，后来买了一批廉价线材复测，问题立刻出现。

第三，Android 15要特别关注插着充电器做软件升级、OTA重启的场景。Type-C状态机在系统重启过程中的复位逻辑，在Android 15上处理不当会导致重启后无法充电直到重新插拔。这个问题在MTK平台上出现过多次，需要在typec驱动初始化时做好状态恢复。

Type-C充电调试这行，说到底没有太多玄学，就是一层一层往下查。硬件上确认管脚电气特性正常，软件上确认协议状态机每一步有据可循，系统层面确认策略引擎没有做多余的干预。遇到问题别慌，把逐层日志拉出来，问题基本就现形了。希望这篇MTK6769平台Type-C充电的全流程拆解，能帮正在跟这个平台较劲的朋友节省几个通宵。