企业官网建设流程全解析

如果你这两年做过瑞芯微平台的开发，多半已经在 SDK 的 dts 里见过i3c0这样的节点了。我第一次在 RK3576 上看到 I3C 时，第一反应是：这跟 I2C 是不是就是改了个名字？后来翻了 MIPI 的规范文档、读了内核 I3C 子系统的驱动源码、又在逻辑分析仪上看了整整一下午波形，才算把这两者的关系和 DTS 里的坑摸清楚。这篇文章就用 RK3576 这个具体平台，聊聊 I3C 为什么比 I2C 快、快多少是真实的、你真正要在项目里用起来 DTS 该怎么写，以及哪些问题是文档不会告诉你的。

如果你只是为了把几个 I2C 传感器接到 RK3576 上，其实可以不看下文直接继续用 I2C。但如果你正在评估新项目要不要上 I3C，或者已经在调 RK3576 的 i3c 节点且波形不对、地址对不上、休眠唤醒后总线卡死，那这篇就是你需要的实操记录。

1. 快十倍？先弄明白 I2C 瓶颈和 I3C 的提速逻辑

1.1 I2C 为什么快不起来

I2C 从 1982 年诞生到现在，标准速率从 100 kHz 一路加码到 400 kHz、1 MHz、3.4 MHz，但真正量产项目里用得最多的还是 100 kHz 和 400 kHz。原因不在协议层，而在物理层。

I2C 的 SCL 和 SDA 都是开漏结构，所有器件共用一根线，低电平靠器件内部拉低，高电平只能靠外部上拉电阻对总线寄生电容充电。也就是说，一个 bit 从低变高，不是驱动器主动“推”上去的，而是电阻慢慢“充”上去的。这个上升沿的时间常数就是τ = R_pullup × C_bus，电容由走线、器件引脚、过孔、连接器共同贡献。

举个例子，一条挂了 4、5 个器件的 I2C 总线，总线电容很容易到 100 pF 以上。如果用常规的 4.7 kΩ 上拉，τ = 4.7k × 100p = 470ns，从 0 充到 70% 需要大约1.2 × τ ≈ 565ns。而 I2C 快速模式 400 kHz 一个时钟周期才 2.5 μs，上升沿就占了将近四分之一，这还没算下降沿、建立保持时间和信号在长走线上的传播延迟。

想把速率提上去就得减小上拉电阻。但电阻太小，低电平时 SDA 上的灌电流(Vcc - VOL) / R_pullup会变大，一旦超过器件允许的 IOL 能力，低电平就压不下去，VOL 超标直接破坏噪声容限。按 I2C 规范里 IOL 最小 3 mA 算，3.3 V 系统上拉电阻下限大约是(3.3 - 0.4) / 3mA ≈ 966Ω，这还没算多个器件同时拉低时的叠加。所以 I2C 提不了速，根子就在这个开漏结构上，不是协议有多复杂。

1.2 I3C 做了什么改变

I3C 是 MIPI 联盟在 2016 年推出的总线标准，引脚还是两根，SCL 和 SDA，但它把电气模型改掉了。I3C 在数据相位使用推挽输出，高电平由驱动器主动推高，不再依赖上拉电阻慢慢充电。这就好比原来是一扇要靠弹簧慢慢拉上的门，现在换成电机直接推，开关速度自然不在一个量级。

I3C 定义了三种主要速率等级。SDR 单数据率模式，SCL 最高 12.5 MHz，每个时钟传 1 bit，算上 ACK/NACK 和帧格式开销，有效数据吞吐大概 8~11 Mbps。HDR-DDR 双数据率模式，在 12.5 MHz 时钟下双沿采样，标称 25 Mbps，后续还有 HDR-TSP/TSL 等更高带宽模式，不过实际 SoC 支持到哪个程度要看控制器 IP。

I3C 不是把 I2C 简单加速，它还引入了几个 I2C 时代完全没法想象的能力。动态地址分配 DAA，设备上电后由控制器分配地址，不需要硬件拨码也不需要担心地址冲突。带内中断 IBI，从设备可以通过总线直接向主控制器发中断请求，省掉一根 GPIO 中断线。热插拔 Hot-Join，设备可以随时接入总线并请求分配地址。这些能力在 I2C 上都需要额外引脚或者复杂的软件轮询才能勉强实现。

但注意，I3C 为了兼容存量 I2C 设备，并没有彻底抛弃开漏模式。在 start/stop 时序、动态地址分配、访问 legacy I2C 设备的交易阶段，总线依然会切回开漏模式。这也是为什么 I3C 总线不能像 SPI 一样无脑跑满速，电气和协议上都有妥协。

1.3 “10 倍”这个数字怎么来的

厂商和社区都爱说 I3C 比 I2C 快 10 倍，这句话严格说没错，但要看对比基准。

所以“快 10 倍”基本是拿 I2C 快速模式+的 1 MHz 和 I3C SDR 的 12.5 MHz 比出来的，约 12.5 倍，说成 10 倍属于保守口径。如果拿最常用的 400 kHz 比，实际上快 30 倍左右。

但有效吞吐不能只看峰值，短帧小包场景下 I3C 也要传地址、命令、ACK，开销占比高，可能只有 5~6 Mbps；连续大块读取时才能吃到接近 10 Mbps 的红利。如果你的应用是每 10 ms 轮询一次传感器读一个寄存器，I3C 的绝对速度优势并不会完全体现出来，真正的收益是动态地址和 IBI 这类结构性改进。

2. RK3576 的 I3C 控制器能力与地址管理机制

2.1 硬件上 RK3576 给了什么

RK3576 是瑞芯微面向 AIoT、工业控制、商显交互的一款 SoC，8nm 工艺，四核 A72 加四核 A53，NPU 算力在 6 TOPS 附近。这颗芯片的外设配置相当全，I3C 也在其中，这一点比之前 RK3588 那代更激进，RK3588 时期主要还在用 I2C。

从 SDK 的 dts 里能看到i3c0、i3c1这类节点，控制器驱动多数走的是 DesignWare 的 I3C IP 内核驱动，也就是drivers/i3c/master/dw-i3c-master.c这一套。compatible 具体是snps,designware-i3c-master还是rockchip,rk3576-i3c，不同版本的 SDK 有差异，动手前先 grep 一下你的内核源码，别照抄网上的节点。

RK3576 的 I3C 控制器支持 SDR 模式，最高 12.5 MHz，也支持 DAA、IBI、Hot-Join 这些 I3C 标准特性。控制器时钟来自芯片内部时钟树，需要确保父时钟频率足够，通常要上到几十 MHz 再分频到目标频率。DTS 里的clock-frequency只是目标值，实际能不能跑到要看时钟树配置、引脚驱动强度、板级走线质量三个因素共同决定。

硬件层面有个容易被忽略的点：RK3576 的 i3c 引脚和 i2c 引脚大概率是复用关系。你在 dts 里开启了 i3c0 就不能再把同一组引脚配成 i2c0，反之亦然。很多板子默认 pinctrl 里已经把 i2c0 配成了i2c0_xfer，你直接加一个&i3c0 { status = "okay"; }会发现 pinctrl 冲突或者 probe 失败。

2.2 动态地址分配、IBI 和热插拔怎么理解

I2C 设备的地址是固定的，要么硬件引脚拨码，要么 ROM 里烧死。I3C 改成动态地址以后，整个思维模式要变。

打个比方，I2C 是酒店房间号提前刻在门牌上，人住进去之前就知道自己在哪间。I3C 是前台入住办理，设备上电后向主控制器报到，报上自己的 PID（Provisioned ID，由制造商、器件型号、实例号组成），控制器现场分配一个地址。这个动态地址理论上每次上电都可能变，只是实际运行中稳定下来后不会乱变。

这就带来调试方式的变化。你用i2cdetect扫 I2C 地址的办法，在纯 I3C 设备上不一定适用。I3C 设备挂在总线上，分配的动态地址不是你在 dts 里写死的那个静态地址。想看设备地址要去 sysfs，/sys/bus/i3c/devices/下会列出总线上的设备。逻辑分析仪抓包时，看到的地址也可能跟 dts 里的reg不一致，不要慌。

IBI 带内中断是 I3C 一个很实用的特性。过去传感器要通知主控有事件，得额外拉一根 GPIO 中断线，电平触发、边沿触发都要配。I3C 里设备可以直接在总线上发起一个带内中断请求，主控制器响应后进入中断服务序列。对 RK3576 这类引脚紧张的板子，省下来的 GPIO 可以干别的事。

热插拔 Hot-Join 在可插拔模组上非常好用，设备插入后自动请求分配地址，不需要系统重启。但要注意，热插拔的电气处理比固定焊接复杂，连接器、线缆、ESD 保护都会影响高速信号质量，做产品不要因为 I3C“支持热插拔”就放松硬件设计。

2.3 和普通 I2C 外设混用的兼容边界

I3C 总线可以挂 I2C 设备，这是协议层面的兼容，但有几个边界必须清楚。

第一，I2C-only 外设只能走 I2C 时序。控制器访问这类设备时会切回开漏模式，用 I2C 的速率和帧格式跟它通信。速率上限通常就是 I2C 的 400 kHz 或 1 MHz，不能指望一个 SSD1306 OLED 在 12.5 MHz 下工作。这说明什么？一条 I3C 总线上如果混挂了好几个 legacy I2C 设备，总线事务会被这些低速访问拖慢，I3C 设备的高速优势只在纯 I3C 交易中体现。

第二，I2C 7-bit 地址空间和 I3C 动态地址空间是重叠的。I3C 控制器在分配动态地址时会避开总线上已经存在的 I2C 静态地址，但这是在 DTS 配置正确的前提下。如果你把 OLED 的地址写成 0x3C，又给一个 I3C 设备指定了动态地址 0x3C，后面的冲突排查会让你怀疑人生。

第三，电气参数要找平衡。I3C 推挽相位不需要上拉，但开漏相位和 legacy I2C 交易需要。我在 RK3576 板子上实测下来，混合总线用 2.2 kΩ 上拉比较稳。4.7 kΩ 在高速阶段上升沿会明显变缓，1 kΩ 虽然边沿好看，但低电平时灌电流接近(3.3-0.4)/1k = 2.9mA，有些弱驱动的 I2C 从设备会拉不住低电平。

3. DTS 配置实操：怎么写一个能稳定跑起来的 i3c 节点

3.1 内核开启 I3C 驱动的正确姿势

在写 dts 之前，先确认内核把 I3C 子系统编进去了。RK 的 SDK 内核一般默认开了，但不排除裁剪过的配置。检查办法：

grep -E "CONFIG_I3C|DW_I3C|I3C_MASTER" .config

如果看到CONFIG_I3C=y或者=m，说明核心子系统在。CONFIG_DW_I3C_MASTER对应 DesignWare 控制器的驱动。我实际遇到过一种情况：内核配置里 I3C 子系统开着，但 RK3576 某个板级 dts 里同时把 i3c0 和 i2c0 都设成了status = "okay"，结果 probe 阶段 pinctrl 申请失败，控制台报pin X already requested。这种问题不看内核日志根本想不到是 dts 层面的冲突。

内核编译选项的位置在Device Drivers -> I3C subsystem下面。如果找不到 I3C 目录，说明你的 SDK 内核版本太老，I3C 子系统合入主线是 2018 年前后的事情，太老的 BSP 可能没有这套框架，那就得先升级内核或者用 vendor 自己维护的老驱动。

模块加载后确认设备节点生成：ls /dev/i3c-*。如果只有 i2c-X 没有 i3c-X，先看dmesg | grep i3c有没有 probe 报错。

3.2 控制器节点：地址、时钟、引脚和上拉

下面是一个我调试 RK3576 时实际用过的 dts 骨架，按 SDK 版本调整后可以直接参考：

&i3c0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i3c0_xfer>; clock-frequency = <12500000>; #address-cells = <3>; #size-cells = <0>; /* I3C target 设备：支持 I3C 的传感器 */ light_sensor: light-sensor@52 { compatible = "vendor,light-sensor"; reg = <0x52 0x52 0x1>; /* 动态地址 静态地址 IBI 支持 */ }; /* legacy I2C 设备：SSD1306 OLED */ oled: ssd1306@3c { compatible = "solomon,ssd1306"; reg = <0x3c>; }; };

这里三个关键点。

#address-cells = <3>是 I3C 子系统的标准写法，子节点reg的三个 cell 按顺序是动态地址、静态地址、是否支持 IBI。注意，这只是内核 binding 文档里的常见约定，不同内核版本可能微调，动手前一定要看你本地内核源码目录下的Documentation/devicetree/bindings/i3c/文档，那里才是最准的。

clock-frequency = <12500000>表示 SDR 模式目标速率 12.5 MHz。如果你的总线上有 legacy I2C 设备，担心兼容性问题，可以先设成<400000>，把整条总线当 I2C 跑通业务，再逐步提速。这是排查问题是协议层还是电气层的最快办法。

pinctrl 里如果 SDK 支持配置驱动强度，高速模式下建议把 drive strength 调高一些。RK 平台的 pinctrl 通常可以配 pull-up 和 drive strength。I3C 高速时上拉不要选太大，pcfg_pull_up_drv_level_2这类宏对应约 2 kΩ 左右的上拉强度。如果我需要明确指定引脚，绝不照抄别人网上的定义，因为 RK3576 不同封装、不同板子的 i2c/i3c 引脚组不一样，必须去查你这块板子的原理图和数据手册。

上拉电阻在硬件上还有一个容易被忽视的点：很多现成模块（比如 OLED、温湿度传感器小板）自身已经带了 4.7 kΩ 或 10 kΩ 上拉。如果你在 I3C 总线上又外挂了 2.2 kΩ 上拉，等效电阻等于并联(2.2k × 4.7k) / (2.2k + 4.7k) ≈ 1.5kΩ，低电平灌电流会明显增大，某些老器件可能顶不住。所以模块自带的上拉建议摘掉，统一在总线端点各放一组上拉，一组就够了。

3.3 挂载 I3C 设备与 I2C 设备的子节点写法差异

I3C 设备子节点和普通 I2C 设备子节点的最大区别在于reg的 cell 数不同。

/* I3C target：reg 3 个 cell */ thermal_sensor: sensor@40 { compatible = "vendor,tsensor"; reg = <0x40 0x40 0x0>; /* 动态地址 0x40，静态地址 0x40，不支持 IBI */ interrupt-parent = <&gpio1>; interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>; }; /* 传统 I2C 设备：reg 1 个 cell，挂在 i3c bus 下 */ touch: touch@38 { compatible = "vendor,touch"; reg = <0x38>; };

I3C 设备如果你的驱动不依赖固定动态地址，可以把第一个 cell 设成 0，让控制器通过 DAA 流程现场分配。静态地址留给设备厂商预设的 I2C 兼容地址，用于控制器在 DAA 之前或 fallback 时访问。

IBI 支持可以在 dts 里通过第三个 cell 设为 1 来声明，但前提是底层驱动真的把 IBI 处理逻辑实现了。我见过一个项目，dts 里开了 IBI，驱动没实现，结果设备一发起中断，总线直接挂死。这种问题排查起来极其痛苦，因为表面现象是“总线偶尔卡住”，背后的原因却是中断请求没人响应。所以 IBI 这类高级特性，确定驱动代码里处理了再在 dts 里开。

I2C legacy 设备的写法跟普通 I2C 子系统下几乎一样。需要注意的是，它的父节点是 i3c 控制器，所以内核 probe 顺序、设备匹配逻辑跟 I2C 不完全相同。如果你的 I2C 设备驱动用的是传统的i2c_driver结构，挂在 I3C 控制器下能不能自动匹配，取决于内核 I3C 子系统是否把 legacy 设备也注册到了 I2C 核心。实测中，V6 内核的 I3C core 会把 legacy 设备暴露给 I2C 框架，老内核则不一定。确认方法就是看/sys/bus/i2c/devices/下有没有你挂的那个地址。

4. 实测那些坑：从逻辑分析仪波形到 OLED 兼容问题

4.1 用逻辑分析仪抓 I3C 波形，怎么判断是不是真的在跑 I3C

I3C SDR 12.5 MHz 模式下，SCL 时钟周期只有 80 ns，想抓清楚波形，逻辑分析仪采样率至少 50 MS/s，建议 100 MS/s 以上。我用的设备是 100 MHz 采样的，抓 SDR 刚好够，再低就只能看到糊成一团的毛刺，根本数不了边沿。

拿到波形后，判断总线是否真的在跑 I3C 而不是降级成了 I2C，有三个标志。

第一看时钟频率。如果 SCL 周期在 2.5 μs 附近，那实际速率只有 400 kHz，说明控制器根本没切到高速模式，可能是clock-frequency没生效，也可能是总线上 legacy 设备导致控制器主动降速。

第二找广播地址 0x7E。I3C 的广播地址是 7h7E，DAA 流程会以广播地址加 ENTDAA 命令码开头。逻辑分析仪解码器如果不认识 I3C，你可以手动在波形里搜索连续的01111110` 地址段。如果总线上从来没有出现过 0x7E，说明 DAA 流程根本没跑起来，设备可能没有被正确识别为 I3C target。

第三看帧结构。I2C 的读操作通常是 START + 地址 + 寄存器地址 + Repeated START + 读数据 + STOP。I3C SDR 帧的 STOP 条件没有 I2C 那么频繁，而且在 DAA 和 CCC 命令阶段会出现一串很长的、不带 STOP 的连续数据段。看多了就能一眼区分。

我还遇到过一个很蠢的情况：逻辑分析仪的地线夹没接好，抓出来的波形全是噪声，当时我还以为是 RK3576 的 I3C 控制器出了问题，后来换了短线、就近接地，波形立刻干净了。高速总线调试，探头接地和线长的影响比你想的大得多。

4.2 0.9 寸 OLED 这类 I2C-only 设备挂 I3C 总线的兼容问题

SSD1306 是 0.9 寸 OLED 最常用的驱动芯片，只支持 I2C（也有 SPI 版本），经典地址 0x3C 或 0x3D。很多人把 OLED 直接挂到 RK3576 的 i3c 总线上，然后发现花屏、黑屏、初始化失败，就开始怀疑 I3C 兼容性不好。其实问题通常在下面几个地方。

先把总线降速验证。如果 dts 里clock-frequency是 12.5 MHz，整条总线默认跑高速，控制器访问 OLED 这个 legacy 设备时会尝试走 I2C 兼容时序。但如果控制器驱动对 legacy 设备的速率协商处理得不好，或者上拉电阻偏大，OLED 的 ACK 就会不稳定。我习惯先设成 400 kHz，确认 OLED 能正常点亮，再决定是否提速。如果 400 kHz 下 OLED 都点不亮，那跟 I3C 关系不大，先查 OLED 供电、复位引脚、I2C 地址是否对。

再查上拉电阻。OLED 模块板上通常会焊 4.7 kΩ 上拉。I3C 总线高速下，这种上拉会让上升沿变缓，legacy 交易时 OLED 可能收不到正确的高电平。我实测把总线总上拉调整到 2.2 kΩ 之后，SSD1306 在 400 kHz legacy 模式下稳定工作。

还有一个地址冲突问题。如果总线上还有其他 I3C 设备，DAA 动态分配的地址恰好落在 0x3C 附近，OLED 就无法正常工作。Linux I3C 框架在分配动态地址时会尽量避开 legacy 设备的静态地址，但有些老版本内核不保证。稳妥做法是在 dts 里给 I3C 设备指定一个明确的动态地址段，跟 OLED 的 0x3C 保持距离。

最后别忘了，SSD1306 这种老器件本身就不是为 I3C 设计的，你不需要它跑多快，能稳定访问就行。不要在 OLED 身上追求 12.5 MHz，这不科学也没有必要。

4.3 休眠唤醒后总线卡死与复位流程

I3C 总线休眠唤醒的问题，和 I2C 类似，但因为多了一个动态地址分配机制，复杂度会更高。

我遇到过最典型的现象：系统 suspend 再 resume 之后，I3C 传感器读回来的数据全是 0xFF 或者读超时，但总线本身看起来没有卡死。查 dmesg 发现i3c master报了 DAA 相关错误。原因很简单：设备在 suspend 时断电了，动态地址丢失，唤醒后控制器没有重新跑 DAA，设备处于“失联”状态。

解决办法分两步。第一步，检查硬件设计，确认 I3C 外设在系统睡眠时是否被断电。如果会断电，就要么改成常供电，要么在驱动里 suspend 回调保存寄存器、resume 回调重新初始化并触发 DAA。第二步，如果硬件已经无法改，可以在驱动里对 master 做一次i3c_master_reset或者调用 RSTDAA（Reset Dynamic Address Assignment）命令，让所有设备重新走一遍地址分配流程。

还有一种是 SDA 被某个设备拉死。现象是总线一直低，SCL 还能翻转但 SDA 始终为低。这种通常是 I2C-only 外设的问题，例如 OLED 在休眠时进入了异常状态。处理方式跟 I2C 时代一样：给 SCL 连续发 9 个时钟脉冲，让从设备释放 SDA，同时把出问题的设备单独复位。I3C 规范里也有对应的总线复位序列，但实际板子上最有效的还是把异常设备断电一下。

在 RK3576 上还有一个小技巧：如果你怀疑是 I3C 控制器状态机乱了，直接在驱动里调用 pm_runtime 让控制器强制 suspend/resume 一次，很多时候比手动操作总线更干净。我在调试时甚至写过一个小工具，通过 debugfs 里的控制器寄存器 dump 来判断状态机卡在哪个阶段，这个比盯着波形猜效率高得多。

5. 项目里到底选 I2C 还是 I3C？我的建议

5.1 适合上 I3C 的场景

如果你的项目有以下任何一个特征，都值得考虑上 I3C。

传感器数量多。总线上挂四五个 I2C 传感器，地址可能互相冲突，就需要地址扩展芯片或者改 PCB。I3C 动态地址直接解决这个问题，设备上电自动分配，不用考虑硬件地址冲突。

有频繁中断的从设备。比如接近传感器、按键控制器、保护芯片，这些设备需要主动通知主控事件。传统方案每个设备占一个 GPIO 中断，四个设备就占四根引脚。I3C IBI 把这些中断合并到总线上，省资源也省软件中断处理复杂度。

对总线吞吐有真实需求。比如高分辨率图像传感器的寄存器配置、大批量读取传感器数据、或者需要频繁读写配置的空间，I3C 的高速率优势能明显降低主控的等待时间。

可插拔模组场景。热插拔能力可以省掉“插上设备必须重启系统”这种尴尬流程。

5.2 现阶段不建议上 I3C 的场景

反过来说，有些情况上了 I3C 反而给自己找麻烦。

外设全是 I2C-only，而且项目生命周期可能就一两年。那没必要为了“新”而上 I3C，继续用 I2C 总线，稳定且生态成熟。

总线走线很长，或者经过连接器转接。12.5 MHz 的信号完整性问题会随着线长、连接器接触电阻、线缆寄生电容急剧恶化。I3C 在没有良好 PCB 设计的情况下，跑 12.5 MHz 非常吃力，飞线调试也许能通，量产就是另一回事。

多主架构需求。I3C 协议支持 Secondary Master，但 Linux 的 I3C 子系统和多数控制器驱动对多主支持并不完善。如果你的系统里有两个 MCU 共用一条总线，I2C 的多主仲裁反而更成熟，别贸然上 I3C。

内核版本比较老的情况。I3C 子系统在主线内核里仍然在快速演进，一些 API 和 dt-binding 都有过变动。用老内核的 SDK 平台，I3C 驱动可能有很多已知 bug，与其填坑，不如先把业务跑起来。

5.3 最后分享一个调试技巧

做 RK3576 的 I3C 调试，我最深的体会是：不要一上来就在 12.5 MHz 的速率下调。

先把clock-frequency设成 400 kHz，把 I3C 当 I2C 使用，把所有外设的业务逻辑调通。这一步能排除掉信号完整性、上拉电阻、驱动 bug 等一大堆变量。业务全部通了之后，再逐步提高速率，每次提一个档，比如 400k → 1M → 4M → 12.5M，每个档位用逻辑分析仪确认波形，同时观察设备是否有偶发通信错误。

这个方法的本质是把“协议栈问题”和“电气问题”分开排查。我在调一个 I3C 温度传感器时，一开始怀疑驱动写错了，后来发现是某块 OLED 模块上的 10 kΩ 上拉把整条总线拉垮了。如果一开始就用 12.5 MHz 调，这种电气问题会伪装成各种协议错误，极其浪费时间。

另外一个容易被忽略的点是：I3C 的动态地址分配对电源稳定性很敏感。DAA 流程中设备需要准确发送 PID，如果供电纹波大或者电源上升缓慢，设备可能在 DAA 中途掉链子。我调试时给 I3C 传感器用的 LDO 输出波纹偏大，一度导致设备“时好时坏”，换成低噪声 LDO 后问题消失。排查 I3C 问题，不要只盯着数字波形，先看电源净化没有。