Type-C音频转接器「PD握手→Hub枚举→Codec初始化」三段式上电时序协同设计手册

PD握手完成≠音频Ready

在设计Type-C音频转接器时，工程师常遇到这样一个困惑：PD握手明明已经成功，但插入耳机后没有声音，或者OMTP检测失效。这类问题的根源不在PD协议本身，而在于三个阶段的时序依赖没有被系统地梳理——PD握手、Hub枚举、Codec初始化是一环扣一环的链路，其中任何一步错位，都会导致量产后反复出现音频掉码、采样率锁定失败等问题。本文以KT系列Codec与LDR系列PD控制器的组合为例，给出一套可量化的三段式上电时序设计框架。

一、系统架构：电源树与信号链

一个完整的Type-C音频转接器，至少包含三颗核心芯片的协同工作。

LDR系列PD控制器负责CC协商与VBUS管理。LDR6028面向单C口DRP转接器，LDR6023AQ面向双C口扩展坞场景，LDR6021/LDR6600则面向需要ALT MODE或多口功率分配的高阶适配器。PD控制器是整个系统的「电源大脑」，决定了什么时候、以什么档位给下游电路供电。

KT系列音频Codec负责USB音频协议栈与模拟输出。KT0234S面向基础USB耳机与会议系统，KT0235H针对游戏耳机的高采样率场景，KT0231H锁定Hi-Res小尾巴市场，KT02F22/KT0201/KT0211提供不同封装与通道数的配置梯度。Codec是系统的「音频出口」，它的初始化完成节点直接决定了用户能否听到声音。

两者之间通常还串着一颗USB Hub芯片（如CM6635），负责将单路USB口扩展为多路downstream端口。这个Hub的枚举延迟，恰恰是工程师最容易忽视的时序黑洞。

二、三段式上电时序图解

阶段一：PD握手（CC协商→VBUS使能）

这是整个上电序列的起点。LDR系列PD控制器通过CC引脚检测线缆连接，完成Discover Identity、Power Negotiation等握手流程，最终向VBUS FET发出使能命令。

⚠️ 参数说明：LDR系列具体时序参数（CC检测响应时间、VBUS使能延迟等）站内未完整披露，以上为参考设计典型值，选型时请向代理商FAE申请原厂EVB实测报告。

PD握手完成的标志不是VBUS输出，而是PD控制器发出「Power Ready」中断信号。 这个信号才是下游Codec和Hub启动的触发源——很多设计错误地把VBUS上电当作启动信号，这是第一个坑。

阶段二：Hub枚举（USB枚举→设备识别）

VBUS稳定后，USB Hub芯片开始与上游Host通信，完成设备描述符请求与配置。

• CM6635类Hub的典型枚举时间约200~400ms（取决于固件复杂度与Host端USB驱动响应速度）。
• 如果Hub固件集成了音频类描述符预加载，枚举时间可压缩至150ms以内。

Hub枚举期间，下游端口的VBUS可能尚未完全稳定。某些设计在Hub枚举完成后还会执行一次USB Reset（约10ms），这段时间Codec绝对不能启动I2S时钟。

阶段三：Codec初始化（I2S时钟→采样率锁定→OMTP检测）

终于轮到Codec登场。KT系列Codec的初始化流程大致是：USB描述符解析→内部时钟建立→I2S时钟建立→音频格式协商→OMTP/CTIA耳机检测。

注：上表中标注的时序参数（Flash加载时间、I2S建立时间等）站内暂未完整披露，KT0234S内置Flash容量与KT0231H集成DSP的具体实现以原厂datasheet为准，请联系FAE确认。

OMTP检测的时序陷阱：KT02F22内置耳机插入/类型自动检测，但有个隐蔽的时序依赖——OMTP检测必须在PD握手完全稳定后执行，否则PD重协商（比如用户突然接入大功率充电器）会打断检测流程，导致Codec误判耳机类型（OMTP vs CTIA）。

三、KT+LDR组合时序匹配决策树

根据转接器的物理拓扑与功能定位，时序设计策略差异巨大。

转接器拓扑判断
├── 单C口（仅充电+音频）
│   └── LDR6028（单口DRP）+ KT0234S
│       关键约束：PD重协商期间禁止Codec执行OMTP检测
│
├── 双C口（充电通过+音频输出）
│   ├── 简单双口：LDR6023AQ（双口DRP，PD3.0，最大100W）+ KT0235H
│   │
│   └── 进阶多口：LDR6600（多口PD3.1，PPS支持）+ KT0231H
│       关键约束：ALT MODE协商期间Codec必须进入低功耗等待态
│
└── 音频+Hub复合型（多USB口扩展）
    └── CM6635 Hub + LDR6023AQ + KT02F22
        关键约束：Hub枚举未完成前不能启动Codec I2S时钟

实战经验：PD握手完整流程（含Source Cap宣告）可能延伸至400~600ms。这意味着在很多情况下，PD握手完成时间比Codec的理论启动时间更晚。如果Codec先于PD握手完成初始化，可能出现USB描述符解析错误。正确做法是：以PD控制器的「Power Ready」GPIO中断作为Codec使能脚的去抖信号，而非简单地用VBUS上电沿触发。

四、典型时序冲突场景与解决方案

场景1：PD握手超时→Codec初始化失败

现象：某些手机在接收到Cable或E-marker芯片响应异常时，会主动终止PD握手并重复尝试，导致握手周期被拉长至2秒以上。此时Codec可能已完成初始化并进入低功耗模式，无法响应后续的USB枚举请求。

解法：在LDR PD控制器固件中实现「软启动延迟」——PD握手完成至少200ms后再释放Codec的使能脚。同时在Codec侧开启「重复枚举」机制，允许在初始化完成后接受新的USB Reset而不重启。

场景2：Hub枚举延迟挤压Codec启动窗口

现象：Hub枚举时间超过预期（如连接HID复合设备时描述符链较长），Codec的启动窗口被压缩，I2S时钟建立时间不足，导致音频输出抖动或爆音。

解法：Hub选择支持「描述符预加载」的固件版本，或者在Hub与Codec之间增加一个GPIO握手信号——Hub枚举完成后主动拉高某一GPIO，Codec检测到该信号后才启动I2S时钟。

场景3：OMTP检测被PD重协商打断

现象：用户插入耳机后正在听音乐，此时外接充电器导致PD发起重协商，VBUS电压短暂中断约20ms，Codec在OMTP检测中途收到VBUS跌落中断，重新执行初始化，耳机类型检测结果被覆盖。

解法：在KT系列Codec的固件中实现「耳机状态锁存」——OMTP检测完成后将结果写入内部寄存器，VBUS跌落不影响该寄存器值（除非物理拔出耳机）。同时建议在PD控制器侧开启「VBUS缓降」功能，将20ms跌落延长至50ms以上。

五、Layout走线时序关键节点

三个节点直接影响时序稳定性：

1. CC走线：LDR PD控制器的CC1/CC2引脚到Type-C座子的走线长度差控制在5mil以内，避免CC协商延迟不对称。

2. I2S时钟走线：KT Codec的I2S_SCK/I2S_WS/I2S_SDO到耳机驱动或外置DAC的走线需严格等长（误差<2mil），I2S时钟建立时间不足会导致采样率锁定失败。

3. 使能信号隔离：PD控制器的Power Ready GPIO到Codec使能脚之间，建议加100Ω串联电阻做ESD保护，同时在Codec端做软件防抖滤波，避免VBUS毛刺误触发Codec重启。

六、OMTP/CTIA兼容性自检表

常见问题（FAQ）

Q1：KT系列Codec和LDR系列PD控制器的时序参数，datasheet里没有明确给出启动延迟，有没有办法确认？

A：站内产品规格书目前未完整披露启动时序的量化参数。建议直接联系代理商FAE申请参考设计指南或EVB实测报告，通常可以获得示波器实测的I2S时钟建立时间与PD握手延迟数据。

Q2：多口USB-C音频转接器（如带USB-A Hub扩展口）应该优先选哪颗PD控制器？

A：多口场景建议优先考虑LDR6600（PD3.1，PPS，多口功率分配）或LDR6023AQ（双口DRP，扩展坞场景成熟验证）。配合KT0235H或KT02F22可以获得音频+充电+Hub三合一方案。具体选型需结合端口数量与功率分配需求评估，联系FAE可协助对接原厂兼容对照表。

Q3：Realtek ALC方案迁移到KT+LDR组合，硬件改版幅度大吗？

A：对于纯USB音频转接器应用，KT系列Codec的I2S接口与USB描述符配置与主流方案兼容，Pin脚定义差异不大，改版主要集中在PD控制器外围（CC电阻网络与VBUS FET选型）。可提交BOM评审需求，由FAE协助对接原厂技术资源。