企业官网建设流程全解析

1. 从一次角色错乱说起：为什么需要IO通知这个功能

做USB-C相关开发的工程师，大概率都遇到过这种场景：设备插上之后，跑在Sink模式（也就是从机/设备端）的设备没有正常拉取电源，反而被主机端识别成了Source（供电方），结果整个链路电压不对，直接触发过流保护或者压根没反应。还有一种更常见的尴尬：一台同时支持双向供电和双向数据传输的设备，在PC、充电器、扩展坞之间来回切换时，角色判断永远慢半拍，插上之后要等好几秒才能稳定工作。

LDR6500这颗芯片，说白了就是用来解决USB-C接口在DRP（Dual Role Port，双角色端口）场景下的角色识别和切换问题的。DRP设备很特殊，它既是潜在的Source，也是潜在的Sink，具体以什么身份工作，要看对面接的是什么。如果接的是充电器，它就是Sink；如果接的是手机，它就要切到Source给手机充电；如果接的是PC，它又要作为Device去和PC通信。问题来了，芯片上电之后默认往哪个方向跑、切换的时机怎么判断、切换过程中插拔事件怎么处理——这些都需要一套明确的通知机制。

LDR6500的IO通知功能，就是一个把芯片内部状态变化实时反馈给外部MCU的机制，同时也允许外部MCU通过IO输入主动触发角色切换。说人话就是：芯片把"我现在是主机还是从机"这个状态，通过一根或几根引脚告诉主控；主控也可以反过来拉某个引脚，强制芯片切到指定角色。这个功能对带主控方案的设备来说太关键了，因为很多产品不是单独用PD协议芯片，而是要让自己的MCU掌握全局——什么时候切Source、什么时候切Sink、切之前要不要先断掉VBUS——这些决策在主控手里，芯片只负责执行PD协议层的握手。

我最早接触LDR6500是在一个双口扩展坞项目上，USB-C上行口既要能接电脑做HUB，又要能接充电器给整机供电，还要能直连手机做OTG。当时用的方案是多个芯片叠加，一个管PD诱骗取电，一个管CC逻辑，一个管数据切换，板子画出来密密麻麻，调试的时候光是排查引脚冲突就折腾了一周。后来换成LDR6500，一颗芯片把CC逻辑、PD握手、角色切换、IO通知全包了，硬件瞬间清爽很多。所以这篇文章想围绕IO通知切换主从模式这个点，把硬件设计、固件配置、踩坑排查完整聊一遍。适合正在用或准备用LDR6500做DRP设备、双向电源、USB-C HUB、多功能Dongle的硬件工程师和嵌入式软件工程师参考。

2. 硬件层先说清楚：LDR6500的引脚分配与角色通知链路

2.1 CC引脚的角色协商过程，为什么不能靠软件盲猜

USB-C口的角色协商，物理基础是CC（Configuration Channel）引脚。一根USB-C线上有两组CC引脚，CC1和CC2，设备通过检测CC引脚上的电压和上下拉电阻配置来判断对面的设备类型。Source端在CC引脚上会接一个上拉电阻（通常是56kΩ或22kΩ，具体取决于电流能力），Sink端则接一个下拉电阻（5.1kΩ），这样一来，当两端物理连接时，CC线上的电平会形成一个可检测的分压结果。

LDR6500内部集成了这些电阻和检测电路，所以外部不需要再额外搭上拉下拉网络。芯片通过检测CC引脚是被对端拉低还是被本端拉出，就能判断当前应该作为Source还是Sink出现。这个过程完全是硬件自动的，不依赖软件轮询——这一点非常重要，因为在设备刚插入的瞬间，VBUS还没有稳定建立，如果靠主控去采样电压后再判断角色，时间上根本来不及，可能已经被对端识别成错误的设备类型了。

2.2 IO通知相关的引脚：D+/D-、GPIO、以及状态输出脚

LDR6500不同封装下引脚配置有差异，但和IO通知核心相关的引脚大致包含以下几类：USB 2.0数据通道D+/D-、CC1/CC2、VBUS检测脚、以及一组通用IO脚。在DRP场景下，D+/D-的状态也需要跟着角色切换——当芯片作为Source时，D+/D-可以直通到下行口，把主控的USB信号送到对端；当芯片作为Sink时，D+/D-又要切换到上行方向，让对端枚举到主控设备。

理解这个链路对IO通知的功能设计很重要，因为一次角色切换不只是CC线上的电气变化，还涉及数据通道的切换、VBUS的接通与断开、以及主控内部状态机的同步。如果主控不知道当前角色是什么，它就无法决定D+/D-的MUX选通方向，也无法决定自己是作为USB Host还是Device去工作。这个时候就需要IO通知引脚把状态实时反馈给主控。

LDR6500通常会把角色状态映射到某一个IO脚上，逻辑高电平表示当前处于Source模式，逻辑低电平表示处于Sink模式（具体的极性可以通过寄存器配置反转）。这其实就是一根现成的"角色指示灯"引脚，主控只要读一次电平就知道当前芯片在以什么身份工作，甚至不需要主动去查询寄存器。

2.3 主控怎么知道芯片状态变了——状态变化中断脚的设计

只靠一根静态电平引脚还不够。假设当前设备作为Sink正在充电，此时用户把充电器拔掉，插上了一台PC，角色需要从Sink切换到Device（这本质上也是一种Sink模式，但要重新做USB枚举）；或者插上去的是一个手机，角色要从Sink切换到Source。这种动态变化的场景，如果主控只在某个固定时间点去读电平，很容易漏掉切换事件。

所以LDR6500还提供一个状态变化中断脚（INT或类似命名）。当角色发生切换、PD协商完成、VBUS上电/掉电等关键事件发生时，这个引脚会产生一个跳变（通常是下降沿），主控收到这个中断后，再去读取芯片内部的寄存器或IO状态，就能拿到准确的角色信息和当前状态。

在硬件设计时，这个INT脚强烈建议接到主控的外部中断引脚上，不要接在普通的GPIO上靠轮询方式读取。原因很简单：角色切换的时机不可预测，可能是几秒后也可能是下一秒，轮询既占CPU又容易错过边沿事件。如果主控的可用外部中断引脚不够，也可以用一个I2C电平转换器辅助，但这会增加成本，一般不太推荐。

2.4 一个典型的主从模式硬件连接框架

下面是一份LDR6500做主控角色的典型硬件连接参考，不同项目可以按需裁剪：

VBUS_DET这个脚容易被忽略，实际上它对角色切换的判断非常有用。LDR6500内部会根据VBUS_DET的电平情况辅助判别外部连接类型——如果VBUS有电且CC检测到下拉，那对面大概率是充电器或电源适配器，芯片进入Sink模式；如果VBUS没电但CC检测到上拉，那对面是设备，芯片进入Source模式。这个逻辑如果只靠CC引脚去判断，在某些特殊线缆或非标设备面前还是会出现误判。

3. 固件和寄存器层面：IO通知切换主从模式的具体执行路径

3.1 先理解寄存器组的角色控制字段从哪里读

LDR6500对外提供了一套基于I2C的寄存器映射，核心控制集中在几个关键寄存器里。角色相关的主要有三大块：模式配置寄存器（设置芯片工作在Source-only、Sink-only还是DRP模式）、状态寄存器（保存当前角色、接插状态、PD协商结果）、以及事件标志寄存器（记录哪些事件发生过，比如角色切换、VBUS变化、CC连接状态变化）。

IO通知要实现的完整链路其实是这样的：芯片内部状态发生变化之后，硬件电路先完成最底层的电气动作（比如把CC引脚从下拉切到上拉），然后更新内部状态寄存器，最后通过INT脚把事件推给主控。主控在中断服务程序里通过I2C读取状态寄存器和事件标志，判断发生了什么事件，再根据应用逻辑决定是否需要进一步操作。如果需要主动切换角色，则反向操作：主控先配置角色控制寄存器，写入新的模式字，芯片再执行实际的CC角色切换。

3.2 内部状态机的切换流转过程

LDR6500内部有一套状态机来管理DRP角色。在DRP模式下，芯片会以固定周期在Source和Sink之间尝试切换，这个尝试过程在USB-C规范里叫DRP Toggle。具体表现就是芯片每隔一段时间把CC引脚配置成一次上拉，然后检测是否有对端下拉接入；如果等了超时时间没检测到，再切换成下拉配置，看是否有对端上拉。这个过程会用特定的DRP时序（Try.SRC和Try.SNK两个时间参数）来避免双方都在反复横跳。

当检测到对端设备后，芯片还需要进行PD协议的物理层握手，协商电压、电流和数据角色。PD协议本身是基于BMC编码的，在CC线上传输，这部分完全由LDR6500内部硬件处理，主控不需要参与。但PD协商的结果，比如对方请求的是5V还是20V，是初次进入还是已经做了一次显式角色交换（Explicit Contract），这些信息会存在寄存器里，主控需要及时读取。

3.3 主控侧读状态的I2C操作示例

假设LDR6500的I2C从机地址是0x25（实际地址需要根据自己的硬件配置查datasheet确认），那么主控读取当前角色的代码逻辑大致如下：

#define LDR6500_I2C_ADDR 0x25 #define REG_DEVICE_STATUS 0x03 #define REG_EVENT_FLAG 0x06 uint8_t role_state; uint8_t event_flag; // 读取事件标志寄存器，确认是否有角色切换事件 i2c_read_reg(LDR6500_I2C_ADDR, REG_EVENT_FLAG, &event_flag, 1); if (event_flag & 0x01) { // bit0: role switch event // 读取当前角色状态 i2c_read_reg(LDR6500_I2C_ADDR, REG_DEVICE_STATUS, &role_state, 1); if (role_state & 0x04) { // 当前是Source模式 set_system_role(ROLE_SOURCE); } else { // 当前是Sink模式 set_system_role(ROLE_SINK); } // 清除事件标志，避免重复响应 i2c_write_reg(LDR6500_I2C_ADDR, REG_EVENT_FLAG, 0x01); }

这里有个细节需要注意：事件标志寄存器通常是写1清零（Write-1-to-Clear），读出来之后，写对应位即可清除该事件。如果不清除，下次读还是会读到同一个事件，导致主控反复处理一个已经处理过的切换动作。这个坑我见过不少工程踩过，代码逻辑看着没问题，但行为就是不对，最后排查下来发现是中断标志没清。

3.4 主动切换主从模式的寄存器写入方法

被动响应IO通知只是基础需求，更常用的场景是主控根据应用逻辑主动发起角色切换。比如产品是一个带电池的移动扩展坞，当电池电量低时，主控希望整机变成Sink去充电；当电池充满且插着U盘时，主控又希望整机变成Source给手机供电。这种切换不能靠用户插拔来实现，必须由主控主动触发。

LDR6500提供一个角色控制寄存器（以REG_MODE_CONTROL为例），写入不同的模式字可以切换芯片的角色模式：

#define REG_MODE_CONTROL 0x01 // 切换到Source-only模式 uint8_t mode_source = 0x02; i2c_write_reg(LDR6500_I2C_ADDR, REG_MODE_CONTROL, &mode_source, 1); // 切换到Sink-only模式 uint8_t mode_sink = 0x01; i2c_write_reg(LDR6500_I2C_ADDR, REG_MODE_CONTROL, &mode_sink, 1); // 恢复DRP模式 uint8_t mode_drp = 0x03; i2c_write_reg(LDR6500_I2C_ADDR, REG_MODE_CONTROL, &mode_drp, 1);

写入模式字之后，芯片内部会先断开当前的CC连接状态，然后按新模式的参数重新开始检测和协商。整个过程是异步的，所以主控写入后不能立即假设角色已经切换完成，而是应该等待下一次INT中断触发，再读取状态寄存器做确认。

还有一点务必注意：在做角色切换之前，主控必须先把VBUS的管理处理好。假设当前是Source给手机充电，你要切到Sink去充电，如果直接切，VBUS上可能还挂着电流，瞬间断开会产生比较大的电压跌落，轻则烧接口，重则影响整块板子的电源稳定性。正确做法是先在系统层面切断VBUS输出，等负载放电完成后再发起切换。

4. 实战案例：双角色充电/数据传输设备如何用IO通知实现无感切换

4.1 设备定义和功能预期

为了让这个机制具体化，我以一个实际做过的产品为例：一个带USB-C接口的便携式采集盒子，一个C口同时承担三种职能：

• 接电脑：作为USB Device，把采集数据传输到电脑。
• 接充电器：作为Sink，给内部锂电池充电。
• 接手机：作为Source，给手机充电或做OTG外设。

三个场景对应三种不同的角色要求，而且用户不会事先告诉设备"我现在要接什么"，设备必须自己判断、自动切换。更关键的是，切换过程不能中断当前正在进行的任务——比如正在往电脑传数据，用户突然把手机插到另一个口上，设备的处理策略是先保证当前的数据传输稳定，延迟切换或拒绝切换。

这类需求在之前用纯硬件方案很难优雅实现，因为角色判断之后物理层的数据通道切换逻辑太复杂，需要一堆MUX和电平转换芯片。LDR6500 + IO通知的方式，主控可以在软件层统一编排整个切换流程。

4.2 硬件连接具体怎么接

这份连接设计里，我把IO通知引脚接到了主控的两个外部中断脚上，而不是普通GPIO：

• ROLE_IO接到主控的GPIOA0，作为普通输入，开机时轮询一次获取初始角色。
• INT_N接到主控的外部中断EXTI0，下降沿触发。
• I2C挂在I2C1总线，速率400kHz，够用且稳定。

特别注意，INT_N引脚在芯片内部是开漏输出，外面必须接一个上拉电阻到3.3V，阻值建议4.7kΩ到10kΩ。如果不接上拉，INT_N永远拉不高，下降沿中断功能形同虚设。这个电阻不要为了省物料去掉，一定会踩坑。

VBUS_DET脚不能直接连VBUS，VBUS在上电时会达到5V甚至20V，而VBUS_DET的耐压范围不支持直接输入，必须先经过分压电阻网络，把电压缩到3.3V以下。分压电阻取100kΩ和20kΩ的组合，既能满足电平转换，又不会在待机时消耗太多电流。

4.3 中断服务程序的完整处理逻辑

整个IO通知切换的灵魂在中断服务程序里。我写了一个精简版本的逻辑框架，实际项目中在这个基础上加了若干产品特有的策略判断：

void EXTI0_IRQHandler(void) { // 清外部中断挂起位，必须第一时间清，否则连续事件会丢失 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0); uint8_t event_flag; uint8_t device_status; // 读取事件标志和状态 i2c_read_reg(0x25, 0x06, &event_flag, 1); i2c_read_reg(0x25, 0x03, &device_status, 1); // 判断角色切换事件 if (event_flag & 0x01) { int new_role = (device_status & 0x04) ? ROLE_SOURCE : ROLE_SINK; // 应用策略：如果在传数据且角色要切走，先挂起切换 if (data_transferring && new_role == ROLE_SINK) { pending_switch = true; } else { // 执行切换流程 usb_mux_switch(new_role); system_power_policy_update(new_role); } // 清事件标志 i2c_write_reg(0x25, 0x06, 0x01); } // 其他事件：VBUS变化、CC连接状态变化等，按需处理 if (event_flag & 0x02) { // VBUS changed event vbus_event_handler(); } }

主控收到角色切换事件后，先判断当前系统状态是否允许立即切换，如果允许，就执行USB MUX切换和电源策略更新，然后清事件标志。如果不允许，就把切换意图挂起来，等当前任务结束后再处理。

我发现这个"挂起切换"的逻辑非常实用。在没有这个机制前，设备在数据传输中如果被插入充电器，主控一看到角色切换事件就立刻把USB MUX切到Device方向，结果PC那边数据传输直接中断。加上挂起判断后，用户的使用体验好了很多——数据传完再自动切换，或者通过上位机提示用户手动确认。

4.4 初始上电时的角色同步

有一个容易遗漏的环节：系统上电时，主控还没开始运行，但LDR6500已经在工作了。如果设备接的是一个充电器，芯片上电后就会快速进入Sink模式开始充电。等到主控跑起来，第一步应该读取当前角色状态，而不是等中断。

因为上电期间可能已经发生过角色事件，如果只在中断里处理，这个事件很可能在中断初始化之前就已经错过。所以我的做法是：初始化I2C和GPIO之后，立即读取一次状态寄存器和事件标志寄存器，把当前角色信息同步到系统变量里。之后再打开外部中断使能，之后的状态变化就不会漏了。

同步读状态的代码和中断里的代码是一套，封装成函数复用，避免两处逻辑分叉后出现不一致。

5. 调试过程中的坑与排查思路，照着这个链路走能省一天时间

5.1 角色状态不更新：是不是中断引脚上拉电阻没焊

一种非常常见的现象：一切功能看起来都正常，CC能检测到对端，VBUS也有电，但主控就是收不到IO通知中断，读寄存器发现角色状态已经变了，只是INT脚没反应。

这个问题八成出在INT脚的上拉电阻上。前面说过，INT_N是开漏输出，必须外接上拉到3.3V。如果这个电阻漏焊、虚焊或者布板时连到了错误的网络，INT_N会一直保持低电平，主控的下降沿中断根本没有触发条件。

排查方法很简单：用万用表量一下INT脚在静态时的电平。正常情况应该是高电平，此时用示波器钩住该脚，人为插拔一次对端设备，应该能看到一个明显的下降沿。如果静态是低电平，优先检查上拉电阻和焊点；如果没有下降沿，检查LDR6500是否进入工作状态、供电是否正常。

5.2 中断风暴：清除事件标志之后仍然反复触发

还有一次遇到一个莫名其妙的现象，主控收到中断后读了状态，清了事件标志，但中断还是持续不断地触发，整个系统被中断风暴拖死。刚开始怀疑是硬件问题，换了芯片、查了PCB走线都没找到根因，后来打开逻辑分析仪抓I2C波形才发现，清标志的写操作没有真正生效。

回看代码，我当初用的是普通I2C写函数，把0x01写到事件标志寄存器地址。但仔细看了datasheet后确认，这个寄存器是"写1清零"类型，直接写0x01按说没问题。但问题在于，这个寄存器是16位的，还有一个高位事件标志字段，当下方字段有多个事件同时被置位时，只写低8位会漏掉其他事件，漏掉的事件会继续拉低INT脚。

解决方法：读取完整的事件标志寄存器内容，把所有非零位全部写回清零，而不是只清自己关注的那一位。此外，在清标志前先禁用中断，清完再重新使能，避免在清标志过程中新事件又置位导致边界竞争。这套组合拳下来，中断风暴的问题再没出现过。

5.3 IO抖动和电气噪声导致的误触发

靠IO边沿通知角色切换，最担心的就是误触发。设备的USB-C口在插拔瞬间，机械接触会产生一系列不稳定的电气抖动，CC引脚上的电平可能在极短时间内来回变化，芯片内部如果处理不及时，可能把一次插拔识别成多次角色切换，INT脚也就跟着多跳几次。

LDR6500内部在CC检测电路上做了数字滤波，正常情况下几十微秒级别的抖动会被滤掉。但在某些大电流设备插入瞬间，VBUS浪涌会在地平面上产生较大噪声，这个噪声可能耦合到INT脚上，导致主控收到一个伪中断。排查时如果发现中断触发时刻和插拔时刻对不上，大概率就是这个问题。

解决思路有三个方向。第一，在INT脚上并联一个100pF到1nF的小电容，滤掉高频噪声；第二，主控在中断ISR里读取状态后，做一个50ms的去抖延时校验，再执行切换动作；第三，PCB布局上把INT脚的走线尽量短，不要和VBUS大电流路径平行走线。

5.4 PD协议协商过程中IO状态被反复改写

还有一次遇到一个更隐蔽的问题：接上设备后，角色切换事件触发了，但LDR6500的状态寄存器里角色字段一直在Source和Sink之间反复变，导致主控不停地切换USB MUX，系统完全没办法正常工作。

后来抓CC线上的波形发现，这是PD协议层的显式角色交换（Explicit Contract）在起作用。对端设备在协商过程中，可能先按照初始检测结果建立了一个角色约定，之后PD协议层又做了一次角色交换，导致芯片状态跟着变。这不是LDR6500的问题，而是PD协议本来的机制——在连接建立初期，角色可能经历一到两次翻转才能稳定。

针对这个情况，主控的软件逻辑不能只盯着某一次角色变化就立刻执行最终动作，而是要做一个稳定判断：在规定时间内（比如500ms），连续读到两次一致的角色状态，才真正执行切换动作。之后再把IO通知中断从"每次都处理"降级为"只在角色稳定后处理"。这样一来，即使协议层做多次交换，也不会导致应用层的反复切换。

5.5 调试工具的建议准备

LDR6500这类芯片的调试，硬件工程师和嵌入式工程师都应该常备下列工具，能省很多没必要的重复劳动：

• USB-C PD协议分析仪：用来抓CC线上的BMC编码和PD协议报文，判断是物理层问题还是协议层问题。
• I2C逻辑分析仪：不需要很贵，支持1MHz采样的就够用，很多问题看时序图一眼就能定位。
• 数字示波器（最好4通道以上）：同时监视CC1、INT_N、VBUS_DET、I2C SCL四路信号，能完整还原一次角色切换的物理过程。

我自己的调试习惯是：先用电表确认静态电平，再用示波器抓动态边沿，最后用I2C逻辑分析仪验证寄存器读写时序。沿着这个顺序排查，绝大多数问题在半小时内能定位到具体环节。

6. 角色切换之外：IO通知机制还能派上什么用场

6.1 作为USB Device和Host的自动识别信号

IO通知最直接的应用就是把ROLE_IO脚接到主控的USB控制器上面。主控的USB外设可以实时知道当前系统是作为Host去枚举外设，还是作为Device被对端枚举。在某些MCU上，USB控制器在不复位的情况下切换Host和Device模式是很麻烦的，但有了这个信号之后，可以先复位USB控制器，再按当前角色重新初始化，整个过程对用户无感。

如果你的主控是双USB控制器（比如一个USB Host一个USB Device），那么IO通知脚可以直接作为MUX的选通信号，省去内部软件控制和外部逻辑芯片。尤其是USB 2.0高速信号，用模拟MUX切换需要注意信号完整性，MUX芯片的导通电阻和寄生电容要尽量小，最好选专门为USB 2.0设计的型号。

6.2 电源策略的触发条件

很多带电池的产品会根据主从状态调整电源策略。设备作为Source给手机充电时，内部电池放电电流大，需要关注温度；作为Sink充电时，又要限制充电电流不超标。IO通知引脚的状态变化如果能在电源管理芯片的EN脚上起作用，可以做到非常快速的电源模式切换，响应周期比软件轮询快一个数量级。

我在一个移动电源兼采集器项目上就是这么干的：ROLE_IO直接接到一颗负载开关的使能脚，当角色切换到Source时，负载开关立刻打开，VBUS上电速度比主控软件控制快很多，手机插上去能瞬间识别到充电。如果用软件响应，从事件发生到VBUS稳定可能要差200ms以上，部分手机在这个空窗期会报"无法识别的USB设备"。

6.3 多设备联动场景下的同步控制

如果一块板子上有多颗LDR6500（比如双C口扩展坞），每颗芯片的INT脚分别接到主控的不同中断引脚，主控根据不同的中断源判断是哪个口发生了事件。这种场景下，IO通知机制的另一个价值是可以实现端口间联动——一个口切到Source给手机充电时，另一个口需要同时切到Sink去取电，两个口的动作必须保持同步。

实现联动的方式有两种：一种是主控收到一个口的中断后，在ISR里直接写另一个口的模式寄存器，这是软联动，响应速度取决于主控代码执行效率，一般几毫秒内完成；另一种是通过外部逻辑门的硬件联动，在干净利落的逻辑控制下可以做到微秒级，但灵活性差一些，只有固定场景适用。我的建议是优先用软联动，代码写清晰一点，几毫秒的响应在USB-C的应用场景里用户完全感知不到差异。

7. 几个和IO通知实践相关的常见问题快答

7.1 IO通知脚能不能并联多个设备共用一个主控引脚

如果多颗LDR6500的INT脚直接用线与方式连到同一个主控中断脚，理论上开漏输出是支持线与的，但问题是主控无法区分中断来自哪个芯片。除非你完全不需要区分端口，否则不要这么接。更合理的方式是每颗芯片单独接一个中断脚，或者用一颗I2C GPIO扩展芯片来多路采集，统一通过I2C中断通知主控。

7.2 没有主控MCU的话，IO通知功能还能用吗

可以。如果产品没有主控，纯硬件方案下，可以把ROLE_IO脚直接接到一颗模拟MUX的选通脚，Data角色切换时MUX自动切换方向，实现纯硬件的Data Role Swap。再配合一些简单的逻辑门延时，还能做到切换时的顺序控制——先断数据再切电源。这种方式不需要写任何代码，但灵活性最差，只适合功能非常固定的产品。

7.3 主控在休眠状态下怎么处理IO通知

休眠场景需要特别设计。如果主控进入低功耗模式，但USB-C口仍然在物理上工作，角色切换事件不应该被遗漏。办法有两个：一是把INT脚接到主控的唤醒引脚上，事件触发时先把主控从休眠中唤醒，再进入ISR处理；另一个是外加一颗低功耗电平锁存器，边沿触发时先把状态锁存住，等主控唤醒后再读取。第一种方案实现更简单，但需要注意唤醒后的初始化时间不能太长，否则对端可能已经超时。

7.4 高速信号模式下D+/D-的MUX切换会不会影响IO通知

USB 2.0高速信号（480Mbps）在切换MUX时，如果MUX的切换时间太长或存在阻抗不连续，会在切换瞬间产生丢包，对端的USB控制器可能会报错。IO通知机制本身不直接影响USB信号质量，但如果主控收到角色切换中断后立刻切MUX，而此时USB总线还在传输事务，就可能引起异常。

解决办法是主控在切MUX之前先拉低USB控制器的使能或进入Suspend状态，让USB总线先静默，再切MUX，最后重新使能控制器。这个流程在USB规范里其实就是标准的Disconnect/Re-enumerate过程，做对了对端设备只会认为是一次拔插，不会认为链路异常。

8. 性能对比：IO通知方式 vs 轮询方式 vs 纯硬件处理

从我个人的项目经验来看，IO通知是DRP产品里性价比最高的方案。它只牺牲一个中断引脚，换来的是主控对角色变化的实时感知能力和控制权。纯硬件方案看着便宜，但真到产品调试阶段，一旦发现切换时序不满足需求，基本只能改版重来，代价远大于一颗引脚的成本。

9. 如何从零快速验证IO通知功能是否正常

如果你也准备在自己的项目上引入LDR6500，建议先搭一个最小验证环路，确认IO通知通路完全没有问题，再去做复杂的应用逻辑。验证方法并不复杂，用一块LDR6500的EVB、一个主控开发板和一颗可调电压源就能完成。

第一步，把LDR6500的I2C接到主控的I2C总线上，ROLE_IO接一个普通GPIO，INT_N接一个外部中断脚，接好上拉电阻和供电。第二步，主控上电后先读一次状态寄存器，打印当前角色。第三步，给USB-C口插上一个标准的USB-C电源适配器（不带数据线，纯充电器），观察INT脚是否有下降沿，主控是否收到中断，状态寄存器是否变为Sink。第四步，拔掉充电器，把一个支持UFP的设备（比如手机或U盘）通过USB-C线连上去，观察状态是否变为Source。

四个步骤全部通过，说明IO通知链路从硬件到软件都是通的，后续再去做产品逻辑就放心多了。如果哪一步没通过，按照前面第5章的排查思路一步步来，基本都能解决。我自己在验证过程中最容易出问题的反而是第一步的I2C地址写错和第三步的上拉电阻虚焊，这两处都是低级错误，但只要犯过一次，后面就长记性了。