1. 先把这个快 10 倍问题拆开看最近在 RK3576 上做传感器接入发现不少人对 I3C 的期待都挂在比 I2C 快 10 倍这句话上。I3C 是 MIPI 联盟在 2016 年前后推出的总线标准定位就是替代 I2C弥补 I2C 在速度、中断上报、地址分配这些老问题上的短板。RK3576 作为新一代 AIoT 芯片原生带了 I3C 控制器DTS 里既有老的 I2C 节点也有新的 I3C 节点用起来确实方便。但快 10 倍这个说法我不能说它错只能说它严重不严谨。I2C 标准模式 100kHz快速模式 400kHz一些新控制器能跑到 1MHz所谓的高速模式 3.4MHz而 I3C 的 SDR 模式下时钟最高可以到 12.5MHz3.3V 电平下如果系统降电压到 1.2V能跑到 25MHzHDR 模式还能更高。拿 I2C 的 400kHz 去比 I3C 的 12.5MHz确实是超过 30 倍的差距但拿 I2C 高速模式的 3.4MHz 去比 I3C SDR 模式的 12.5MHz就只有 3 倍多。所以准确说I3C 比 I2C 快 10 倍这句话在多数场景下成立但机制远不止提频这么简单。更重要的是I3C 的价值不只是快这一个点。它解决了 I2C 总线上一大堆历史遗留问题从设备不能主动上报事件、设备地址要靠硬件引脚跳线避免冲突、多主仲裁效率低、没有数据校验。如果只盯着速度看那就错失了 I3C 一半以上的实用价值。这篇文章我会结合 RK3576 平台把 I3C 的特性、和 I2C 的差距、以及设备树配置里最容易踩的坑一次说清楚。2. I3C 到底是什么从 I2C 的痛点说起2.1 I2C 用了几十年痛点也积累了几十年I2C 是 1982 年飞利浦搞出来的总线当年设计的时候面向的是简单的板级低速外设比如 EEPROM、RTC、温湿度传感器。它的物理层是开漏加外部上拉也就是说设备只能把总线拉低不能主动拉高高电平全靠上拉电阻慢慢充上去。这个设计带来两个结果一是它天生适合多设备共用总线因为谁都能拉低不存在谁的输出直接顶谁的问题二是信号上升沿特别慢频率越高越难看所以 I2C 跑不快是物理层决定的不是协议层不想跑快。除了速度I2C 还有几个让人头疼的地方。第一从设备不能主动找主机说话。传感器检测到异常只能等主机轮询才能上报。第二设备地址是静态的同一型号的芯片出厂地址固定要挂多颗就得用地址引脚跳线板子布线时就得提前留位子。第三总线上完全没有校验I2C 的 ACK/NACK 只能说明这个地址有人理我不能说明数据没被干扰。第四多主仲裁虽然存在但在异常处理上很粗糙总线锁死的情况做过的都懂。这些问题在传感器数量少的年代不算事但放到现在的手机上摄像头、光线传感器、距离传感器、陀螺仪、气压计密密麻麻挂一条总线痛点就被无限放大了。MIPI 联盟当时推 I3C就是冲着解决这些问题去的。2.2 I3C 的几个核心能力CCC、IBI、热加入I3C 最大的革新是引入了一套公共命令代码CCCCommon Command Code机制。CCC 不是某个设备私有的命令而是所有 I3C 设备都必须理解的总线级命令。比如直接地址分配DAADynamic Address Assignment、进入 HDR 模式、设备复位、设备级终止等等都是通过 CCC 来完成的。有了 CCC主机可以在运行时统一管理总线上的设备而不用关心每个厂商私有的寄存器协议。然后是 IBIIn-Band Interrupt带内中断。这个词在 I3C 里非常关键。以前 I2C 设备要上报事件通常拉一根独立 GPIO 去中断控制器要么靠主机高频轮询。I3C 直接把这个中断信号塞进了总线数据线里从设备想报告事件就主动在总线上发起一个 IBI 请求主机收到后安排一个时段接收附带的数据。一颗传感器芯片五六个事件源每个都能主动上报不需要额外的中断引脚。还有热加入Hot-Join。这个概念对应到实际场景就是系统已经跑起来了用户插入一个模块模块上有一颗 I3C 从设备。主机可以通过 I3C 的热加入机制发现新设备给它分配动态地址完成入网全程不掉电、不重启总线。这在服务器、可插拔传感器模组、车载电子里非常实用。动态地址分配DAA是另一个省心点。I2C 时代地址冲突要靠硬件跳线I3C 时代从设备先以初始地址出现在总线上主机通过 DAA 流程给每颗设备分配一个唯一的动态地址。同一批传感器往总线上挂多少颗都可以不需要关心出厂地址撞不撞车。这个特性对于量产设备同一板卡型号传感器品牌随缘分的情况简直救命。2.3 I3C 向下兼容 I2C并不是一句空口号I3C 在设计时有一个硬性要求不能把存量 I2C 设备全部扔掉。所以 I3C 总线上可以同时挂 I3C 从设备和传统 I2C 从设备主机和 I2C 设备之间继续用老的 I2C 时序通信和 I3C 设备之间用新的时序通信。总线会动态切换模式。不过这里有个细节要注意同一时刻总线上只会跑一种协议格式I3C 主机会通过 CCC 命令让总线在 SDR、HDR 等模式之间切换。传统 I2C 设备接收到非 I2C 格式的信号时不会响应所以不会捣乱。反过来I3C 设备都能理解老 I2C 格式的数据包方便从老平台平滑迁过渡。这个兼容性对选型影响很大。比如你现在手上有一批成熟的 I2C 传感器RK3576 板子上先把 I3C 控制器配成兼容模式老传感器照样能用等下一代传感器换了 I3C 接口同一套板子改个 DTS 就切过去。这是很典型的迁移路径。3. 快 10 倍背后到底快在哪几步3.1 物理层从开漏变推挽边沿速度完全不同I3C 的 SDRSingle Data Rate模式从物理层上就和 I2C 不一样。I2C 是开漏加外部上拉I3C SDR 模式在常规传输时用的是推挽输出。推挽输出的意思是驱动器既能灌电流拉低也能输出电流拉高不需要靠电阻慢慢把电平充上来。信号上升沿的时间可以压缩到纳秒级这就把频率瓶颈彻底解开了。做一个简单的估算I2C 快速模式要求信号上升沿时间 t_r 不超过 300ns为了满足这个要求总线电容和上拉电阻必须控制在很严的范围内这也是为什么 I2C 布线稍微一长、一多挂几颗芯片波形就开始变形。I3C SDR 模式在 12.5MHz 下一位周期是 80ns如果还用开漏那种慢慢爬坡的方式波形根本没法看。推挽输出让快成为可能这才是 10 倍速度差背后的物理本质。当然推挽输出带来的第一个限制就是电平兼容性。传统的 I2C 设备支持 5V 传输而 I3C 标准把总线电平下调到了 3.3V 以下甚至推荐 1.2V。如果总线上挂了老式 5V I2C 设备直接接入 I3C 总线的电平体系是危险的需要做电平转换或干脆不兼容。这一点在方案选型时比速度问题更值得提前确认。3.2 SDR、HDR-DDR、HDR-TSP数据模式逐级提速I3C 的数据传输模式分几档理解这些档位是看懂快 10 倍说法的关键。SDR 模式是基础模式它刻意保留了 I2C 的帧格式元素SDA 上每 bit 传输一位数据但 SCL 时钟最高可以达到 12.5MHz 到 25MHz 这个量级取决于总线电平是 1.2V 还是 3.3V。这个模式下的速率已经远超 I2C 高速模式。HDR-DDRHigh Data Rate Double Data Rate模式则是在时钟的上升沿和下降沿都采样数据相当于把同样频率下的数据传输量翻倍。从设备在 DAA 流程被分配好动态地址之后就可以通过 CCC 命令进入 HDR-DDR 模式。简单说SDR 跑 12.5MHz 时HDR-DDR 在同等时钟下可以做到 25Mbps 的实际数据吞吐。HDR-TSPTernary Symbol Protocol和 HDR-TSLTernary Symbol Legacy更复杂一点它们用三进制符号在一个时钟周期里传输超过一个 bit 的信息是面向更高吞吐量场景的模式消费类 SoC 的控制器不一定都实现了RK3576 的 I3C 控制器是否支持可以查芯片手册不要默认它支持所有 HDR 变种。模式物理机制参考速率数据吞吐特征I2C Standard开漏静态地址100kHz1 bit/时钟I2C Fast开漏静态地址400kHz1 bit/时钟I2C High-Speed开漏静态地址3.4MHz1 bit/时钟I3C SDR推挽动态地址12.5MHz-25MHz1 bit/时钟I3C HDR-DDR推挽双沿采样可达 25MHz2 bit/时钟I3C HDR-TSP/TSL推挽三进制符号视实现而定2 bit/时钟这张表里最值得记住的一点是I3C 的快不只是时钟频率高而是协议层通过 DDR、三进制符号等方式进一步压榨时序带宽。如果你只把 I3C 当成频率拉到 12.5MHz 的 I2C那仍然低估了它。3.3 更隐蔽的增益省掉枚举、轮询和控制开销I3C 比 I2C 快的另一个层面藏在控制开销里。I2C 模式下主机想读取一颗传感器的数据需要先发设备地址加寄存器地址再切换读写方向等从设备响应每个环节都有固定开销。I3C 的 DAA 机制让主机能够维护一张总线设备表配合 CCC 命令做私有传输Private Transfer时目标设备地址字段更短模式切换更高效传输固定长度数据时协议开销减少了。打个比方I2C 就像一条单车道乡道每次会车都要减速I3C 则是一条双向四车道城市快速路不仅限速提高入口匝道还设计得能连续汇入车流。实际测下来在同样的传感器读取场景下I2C 400kHz 读 16 字节可能需要 500 微秒左右I3C SDR 模式下同样操作能压到几十微秒这还没算上 IBI 带来的事件主动上报减少的轮询时间。对于传感器数据采集系统IBI 的增益有时候比带宽还重要。I2C 时代触摸屏控制器每毫秒要主机轮询一次是否有触摸事件I3C 时代触摸芯片在有事件时才主动发 IBI主机在中断里响应。这直接改变了整个系统的 CPU 占用模型。快 10 倍不只是单次传输快 10 倍而是整条数据链路上省掉的时间更可观。4. RK3576 平台的 I3C 控制器资源和驱动适配情况4.1 RK3576 的 I3C 外设布局大概什么样RK3576 是瑞芯微面向 AIoT、边缘计算和消费电子方向出的新一代平台外设资源比老型号丰富不少。I3C 控制器和传统的 I2C 控制器是独立的两套资源不是同一个控制器兼有两种模式。这点很关键我就见过有人以为把 I2C 节点里的 compatible 改成 I3C 就能用实际上完全不是一回事。从 SDK 默认设备树和手册的信息来看RK3576 保留了多个 I2C 控制器用于常规外设也提供了 I3C 控制器用于需要高速、更多传感器接入的总线。我在实际调试中主要使用的是 I3C0 这一路它对应的引脚可以复用为 I3C 的 SCL/SDA时钟源和电源域在 CRUClock and Reset Unit和 PMU 里都有独立控制。配置 DTS 之前最关键的一步是查自己板卡上的 I3C 引脚有没有和其他外设打架。RK3576 的引脚复用非常灵活但也意味着 PinMux 配置错了I3C 怎么调都起不来。我会在下一节给一个具体操作顺序避免大家直接抄节点结果跑不通。4.2 Linux 侧 I3C 软件栈i3c core 与控制器驱动分层Linux 在 4.20 左右开始合入 I3C 子系统代码路径是drivers/i3c/分两层drivers/i3c/master/是各种控制器驱动drivers/i3c/的 core 部分负责总线枚举、CCC 命令、设备生命周期管理。RK3576 的 I3C 控制器驱动在 BSP 里一般会注册为rockchip,rk3576-i3c的 compatible 字符串。这个控制器 IP 和 DesignWare 的 I3C master 控制器有很深的血缘关系很多寄存器布局沿用了 dw-i3c-master 的风格。但瑞芯微在适配时时钟、电源、复位、引脚这些和 SoC 强相关的部分都做了本地化处理。所以你在看驱动代码时会看到平台驱动部分主要处理 clocks、pinctrl、power domain而协议栈部分大量复用了 DesignWare 的寄存器操作逻辑。设备在 I3C 子系统里的表示方式和 I2C 也有区别。I2C 子系统用i2c_client表示挂在总线上的设备I3C 子系统用i3c_device。用户空间接口方面内核提供/dev/i3c-N设备节点可以通过 i3ctransfer 这类工具直接发起 CCC 命令或私有传输对调试非常方便。4.3 为什么同一个控制器既能跑 I3C 又能兼容 I2C 设备前面说过I3C 总线协议向下兼容 I2C 设备。在 Linux 的 I3C 子系统里这种兼容体现在两个层面。第一个层面I3C 控制器总线上可以挂一个或多个传统 I2C 从设备。DTS 里直接在 I3C 节点下面声明compatible为某个 I2C 设备驱动的节点并指定静态地址内核会把这类设备归入 legacy I2C 设备管理。总线在跟它们通信时I3C 主机会退回到 I2C 时序。这样板子上旧设备完全不用动新设备走 I3C 特性一个控制器全搞定。第二个层面I3C 设备在 DAA 完成后会被分配动态地址驱动可以基于动态地址通信也可以继续用静态地址。具体策略取决于从设备的能力和驱动实现。我在 RK3576 上调的一颗传感器就支持静态地址和动态地址同时存在驱动配置时同时给了两条路径一处通信失败可以切另一处对量产调试很有价值。所以如果你在设备树里看到某个 I3C 控制器节点下面既有reg是三段式的 I3C 设备也有reg是单段地址的 I2C 兼容设备不要觉得奇怪。这正是 I3C 兼容策略的实际落地形态。5. DTS 配置实操在 RK3576 上把 I3C 跑起来5.1 控制器节点的骨架与关键属性解析RK3576 的 I3C 控制器节点在 SDK 默认 DTS 里通常是disabled状态。我们要做的是把它打开同时确认引脚、时钟、中断都配置正确。我给出一个基于常见 SDK 结构的示例具体寄存器地址和中断号请以你手上的 TRM 为准i3c0: i3cfec00000 { compatible rockchip,rk3576-i3c; reg 0x0 0xfec00000 0x0 0x1000; interrupts GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH; clocks cru CLK_I3C0, cru PCLK_I3C0; clock-names i3c, pclk; pinctrl-names default; pinctrl-0 i3c0_xfer; #address-cells 3; #size-cells 0; status disabled; };这里每个属性都有讲究。compatible决定了内核匹配哪个驱动reg是控制器的寄存器窗口基址和长度中断号一定要对照 SDK 默认 DTS 和 TRM不能想当然我就见过因为照抄其他板卡中断号导致中断一直触发不起来的例子。clocks和clock-names是 CRU 侧提供的模块时钟和 PCLK少配一个可能在寄存器读写时直接挂死。#address-cells 3; #size-cells 0是 I3C 总线节点的固定写法因为 I3C 子设备的地址编码需要三段 reg 表示动态地址、静态地址和保留字段。不要图省事改成 1 段否则内核解析 I3C 设备地址会直接报错。5.2 挂接 I3C 设备动态地址和静态地址在 DTS 里怎么体现I3C 子设备的 DTS 写法和 I2C 设备节点很接近但 reg 的含义完全不同。I2C 设备的 reg 是 7 位静态地址I3C 设备的 reg 由三段组成具体规则以内核 binding 文档为准。简化理解如果设备由主机通过 DAA 动态分配地址reg 的动态地址字段可以填 0如果设备有一个出厂就定死的静态地址也要保留对应字段。下面是个示例i3c0 { status okay; pressure_sensor: pressure-sensor2e { compatible vendor,pressure-sensor; reg 0x0 0x2e 0x0; }; };status okay是开启控制器的关键一步同时父节点和子节点的 status 都要检查。reg 0x0 0x2e 0x0表示这一段里动态地址不指定、静态地址是 0x2e、保留字段填 0。实际工作中不同内核版本对 I3C 设备 reg 的解析略有差异我建议动手配置前花十分钟打开内核源码Documentation/devicetree/bindings/i3c/目录下的文档读一遍比自己瞎试高效得多。另外一个容易忽略的点是 I3C 设备节点里通常还会包含中断相关的属性比如 IBI 事件映射。IBI 不是独立的中断引脚而是总线上的带内信号因此 DTS 里不会出现gpio中断描述。你要进入驱动层通过i3c_device_request_ibi()这类 API 去注册 IBI 回调而不像 I2C 外设那样在 DTS 里声明一个interrupt-parent。5.3 挂接老 I2C 设备兼容模式怎么声明总线上如果有老式 I2C 设备同样直接在 I3C 控制器节点下声明但 reg 的编码方式不同。以一颗常见的 I2C 触摸控制器为例i3c0 { status okay; touch5d { compatible some,touch-controller; reg 0x5d; }; };这里 reg 只有一段表示 7 位静态地址 0x5d。内核 I3C 子系统识别到这种写法后会把设备归为 legacy I2C 设备处理。此时这个 I2C 设备的驱动不需要做任何修改只要它的驱动模型是基于i2c_client的就能继续在 I3C 控制器下工作。这个兼容模式最实用的场景是产品迭代第一版产品用 I2C 触摸屏第二版换成 I3C 触摸屏DTS 里改动一个节点即可PCB 上 SCL/SDA 连线完全不用动。但要注意电平问题老 I2C 设备如果工作在 5V而 RK3576 的 I3C 引脚电平体系是 3.3V 或更低就需要做电平转换不能直接接这是我踩过最实际的坑之一。5.4 引脚、电平、上拉电阻I2C 的调试经验不一定能用I3C 和 I2C 在硬件设计上有一个显著差异就是上拉电阻。I2C 需要外部上拉电阻阻值直接影响上升沿和信号质量I3C 的推挽输出阶段并不依赖上拉电阻拉高但总线上挂着老 I2C 设备时总线上仍然存在需要上拉的时段。实际板卡设计时I3C 数据线通常仍然会放上拉电阻阻值选择要考虑挂载设备数和总线电容。RK3576 的开发板参考设计一般会给 1k 到 2.2k 欧姆的上拉。如果上拉太小推挽驱动在拉低时会多消耗电流长期工作可能发热上拉太大兼容 I2C 设备时上升沿可能不达标。这块建议直接按参考设计来别自己乱创新。电平方面还要额外注意 RK3576 的 I/O 域配置。RK3576 的引脚电平由对应的 VCCIO 电源域决定如果 I3C0 引脚所在的电源域被配置成 1.8V那么传感器也必须选支持 1.8V 的型号。I3C 标准本身推荐低电平操作1.2V 下 SDR 可以跑到更高频率但市面上许多传感器还停留在 3.3V 或 1.8V选型时优先确认传感器支持的电平范围再决定 I/O 域怎么配。5.5 总线速率到底在哪里配不少人有疑问I2C 在 DTS 里有clock-frequency属性可以配 400kHz 或 1MHzI3C 呢答案是I3C 的 SDR 速率并不像 I2C 那样通过一个简单的总线频率属性直接配置而是由控制器内部的时序参数和输入时钟分频决定。不同实现下速率配置入口不一样有的通过通用属性指定 SDR 最高频率有的直接由驱动里的时序参数表控制。这种差异恰恰是 I3C 相对 I2C难配的地方。I2C 的 clock-frequency 是总线级统一属性I3C 却可以针对不同设备等级协商时序甚至在同一条总线上对不同设备用不同的时序参数。好处是灵活性高坏处是调试时不能只盯着一个属性改。我调试 RK3576 的 I3C 时先确认了输入时钟频率再看驱动里的 SDR 时序配置最后才确定实际跑在多少 MHz。理解这一点后你就不会到处找i3c bus-frequency这个属性了。它不是一个标准的通用属性改时序要从时钟源和控制器时序参数入手。6. 调试实录RK3576 上跑 I3C 的经典翻车现场6.1 动态地址分配失败总线像睡着了一样现象I3C 控制器已经status okay驱动也 probe 成功但 dmesg 里看不到从设备枚举完成拿逻辑分析仪看总线感觉像是主机一直在发东西从设备没有任何回应。排查思路先确定从设备的上电时序。I3C 从设备必须在 DAA 之前完成内部初始化如果从设备的电源晚于主控制器开机的 DAA 窗口就错过了主机找不到设备是很正常的。其次检查从设备是否真的处于 I3C 模式有些设备出厂默认是纯 I2C 模式第一次接入 I3C 总线前需要通过厂商专用流程开启 I3C 功能。我当时遇到的情况是电源域配置不对从设备的 VDD 根本没有起来直到我在 DTS 里补上regulators相关的电源节点问题才解决。所以排查这类问题时先别急着怀疑 I3C 协议先确认电源树。6.2 逻辑分析仪抓到的波形怎么看都不对现象SDR 模式下逻辑分析仪抓到的 SDA/SCL 波形并不是 I2C 那种熟悉的锯齿状边沿上升沿非常陡看起来有点方。而且从设备地址段经常和预期对不上。这是正常的。I3C 的 SDR 模式虽然保留了一些 I2C 帧的视觉特征但协议细节完全不同比如地址字段可以携带 I3C 特有的奇偶校验位读写的 ACK 处理、启动/停止条件的时序也和 I2C 不一样。用逻辑分析仪调试 I3C 时不能按 I2C 解码器硬解要选择支持 I3C 解码的分析仪或在抓包时先抓 CCC 命令交互确认 DAA 成功后再看私有传输。这个小节不展开协议细节只想提醒一句看到 I3C 波形和 I2C 不一样先怀疑自己预设错了而不是怀疑信号坏了。6.3 IBI 中断风暴把 CPU 吃满现象从设备频繁上报事件CPU 占用率飙升甚至出现中断风暴。日志里能看到大量 IBI 请求被处理系统其它任务被饿死。原因通常是驱动处理 IBI 的流程太慢或者 IBI 处理函数里做了 spi/i2c 之类的同步读写在原子上下文被卡住。另一个常见原因是 IBI 屏蔽逻辑没做好设备一直发请求主机一直响应。我在 RK3576 上遇到过一次是触摸屏的 IBI 触发了后续的固件升级流程每次 IBI 都触发一次重刷死循环。最后把 IBI 回调里的状态机补全保证同一事件不重复处理问题就消失了。调试 IBI 一定要记得事件上报是异步的处理不能重度阻塞。6.4 长距离走线加低速老设备SDR 速率上不去现象I3C 和一颗老 I2C 设备混挂SDR 最高速率上不去或者老设备工作不稳定。原因是 I3C 能跑高速的条件是总线上所有设备都能接受快速切换和较陡的边沿老 I2C 设备虽然兼容但从设备本身的输入缓冲速度可能跟不上。解决办法就是限制整个总线在 SDR 模式下的最高速率牺牲一点速度换稳定性。这类混挂场景在我的项目里比较多比如指纹模组走 I3C同时板载 EEPROM 是 I2C 的。最终我选择把速率降到 6MHz 左右两边的稳定性都回到正常。如果你希望 I3C 始终跑在 12.5MHz 以上建议老 I2C 设备单独挂 I2C 控制器不让它拖累 I3C 总线。6.5 常见问题速查表现象可能原因排查方向设备枚举不出来从设备未上电、I3C 模式未开启检查电源树、厂商专用初始化DAA 一直重试静态地址冲突或时序冲突检查 dts reg 地址抓 CCC 包I3C 速率上不去电平太高或总线电容太大检查 VCCIO 电平、上拉电阻、挂载数量混挂 I2C 设备不稳定电平/速率不兼容降速、分总线IBI 丢失设备配置的 IBI payload 未注册检查request_ibi回调中断风暴IBI 处理不及时、未屏蔽状态机去重、异步处理7. 一些经验延展I3C 适合做什么不适合做什么回头总结一下在 RK3576 上折腾 I3C 的体验。I3C 最合适的是多个传感器通过一条总线挂在 SoC 上、每个传感器还要主动上报事件的场景。比如手机/平板的握持检测、健康监测的 PPG 传感器阵列、车载的多路环境传感器这类场景下 IBI 和动态地址带来的收益远大于速度本身。另一个合适场景是安全芯片或者摄像头模组它们通常有较大的身份信息或校准数据需要快速读取I3C 的吞吐量能显著缩短启动时间。不适合的场景我列两个。第一个是 5V 电平的老旧外设比如某些工业传感器、EEPROM 扩展模块电平不兼容会让 I3C 直接失去意义不如继续用 I2C。第二个是长距离板间通信I3C 是为短距离板级互连设计的推挽输出在大电容、长走线场景下是个灾难超过 20 厘米且无法控制走线阻抗时别硬上 I3C。最后分享一个实操小技巧调试 RK3576 的 I3C 时先把 I3C 控制器当作 I2C 控制器用用一颗最简单的 I2C EEPROM 做连通性测试确认引脚、时钟、电压域都没问题后再切换成 I3C 模式挂真正的 I3C 设备。这样可以把引脚配没配对和I3C 协议跑没跑通两个问题分开排查省去大量无效定位时间。我在这块踩过的坑多数集中在电源域和引脚复用上希望各位少走几步弯路。