企业官网建设流程全解析

1. 为什么要在 Jetson Nano 上折腾 MCTP 这件事

第一次接触MCTP（Management Component Transport Protocol，管理组件传输协议）的人，十有八九是从一份芯片手册的寄存器表里看到它的，然后一头雾水。它不像 TCP/IP 那样有铺天盖地的教程，也不像 I2C、SPI 那样简单到可以拿示波器直接看波形。它夹在两者之间——一个专门为板内管理通道设计的轻量协议，跑在 SMBus/I2C、PCIe VDM、串口甚至自定义总线上，承载的是 BMC 与各种管理芯片之间的控制报文。

这次要聊的场景很具体：手里有一块Jetson Nano，想把它当成一台 BMC（Baseboard Management Controller，基板管理控制器）来用，去和一颗博通（Broadcom）交换芯片做 MCTP 交互，把链路先打通、把报文先收发起来。这个组合听起来有点野，但恰恰是入门 MCTP 最划算的一条路。原因在于：真实的服务器 BMC 通常是 ASPEED 的 AST2500/AST2600，配套的 SDK 封闭、文档要签 NDA、调试手段有限，一旦报文不通，你很难判断是自己的问题还是平台的问题。而 Jetson Nano 跑的是标准 Linux，I2C 控制器暴露得干干净净，i2cdetect、i2cset、逻辑分析仪随便上，出问题能一层层往下剥。至于博通交换芯片，它在数据中心交换机、企业级网卡方案里出镜率极高，MCTP over SMBus 的支持是标配，寄存器手册和 MCTP 命令集相对齐整，作为对端设备来练手非常合适。

所以这篇内容适合谁看？三类人。第一类是刚进服务器管理固件方向的工程师，天天听人说 PLDM、MCTP、NC-SI 但没动过手，需要一个能跑起来的最小闭环。第二类是做嵌入式 Linux的开发者，板子上有多个管理芯片需要通过 SMBus 互联，想搞清楚 MCTP 到底比裸 I2C 多解决了什么问题。第三类是硬件/系统验证岗，需要在早期 bring-up 阶段确认 BMC 与交换芯片之间的管理通道是否物理通、协议通。不管你是哪一类，只要你会用 Linux 命令行、看得懂寄存器表、知道 I2C 有地址和寄存器这两个概念，后面的内容就能跟着做。

需要先讲清楚一件事：MCTP 不是"跑在网线上的协议"，它是管理平面协议，物理承载层可以换。你在 Jetson Nano 上要做的事情，本质是"把 MCTP 报文封装进 SMBus 的字节流里，通过 I2C 时序发出去"，然后在交换芯片那一侧被解析出来。理解这个分层，后面所有配置参数才有意义。

2. MCTP 到底解决了什么问题：分层设计与选型考量

2.1 裸 I2C 做管理的三个硬伤

很多人第一反应是：BMC 和芯片之间用 I2C 直连不就行了？读寄存器、写寄存器，多简单。小规模场景确实够用，但只要设备一多、命令一复杂，裸 I2C 的三个问题就会同时爆发。

第一个是寻址空间太窄。I2C 的 7 位地址只有 128 个，实际可用还更少，一颗芯片内部往往有几十上百个"逻辑管理实体"（比如温度传感器、风扇控制、固件更新模块、事件日志），你没法给每个实体分配一个 I2C 地址。传统做法是靠"设备地址 + 寄存器偏移"来区分，但这样一来，报文格式就完全私有化了，换一颗芯片就得重写驱动。

第二个是没有消息边界。I2C 是一次传输一串字节，靠 START/STOP 界定。但管理命令通常是"请求-响应"模型，需要知道哪一段是消息头、哪一段是负载、这条消息是给谁的、要不要回复。裸 I2C 完全没有这层语义，全靠上层自己约定，一旦总线出错重传，很容易把半条消息当成完整消息。

第三个是没有多路复用和分片机制。一条管理消息可能很长（比如固件分片），而 SMBus 单次传输有长度限制。没有标准的分片/重组机制，每个厂商都得自己发明一套。

MCTP 的价值就在于它把这三件事标准化了。它在传输层定义了消息头（包含目的 EID、源 EID、消息类型），在下面一层定义了"传输绑定"（Transport Binding），负责把 MCTP 包塞进具体的物理总线。这样上层应用只需要关心"我要给 EID 0x09 发一条类型为 0x02 的控制消息"，完全不关心底下是 SMBus 还是 PCIe。

2.2 分层模型与关键术语对齐

先把术语钉死，不然后面看寄存器手册会一直卡壳。MCTP 的分层大致是这样：

几个必须记住的概念：

• EID（Endpoint ID）：MCTP 网络里的逻辑地址，8 位，取值范围 0x08~0xFE 是动态/静态可分配的端点，0xFF 是广播。它跟 I2C 的 7 位地址是两套东西，千万别混淆。一颗物理芯片可以有多个 EID。
• Message Type：标识这条消息属于哪个协议族。比如 0x00 是控制类（Control），0x01 是 PLDM，0x02 是 NC-SI over MCTP。控制类消息是所有 MCTP 端点必须支持的，用来做能力发现。
• Tag & TO（Tag Owner）：传输层头里的 3 位 Tag 加 1 位 TO，用来做请求与响应的关联。并发多条消息时靠它区分。
• SOM/EOM：Start of Message / End of Message，分片标记。一条长消息被切成多包时，第一包 SOM=1，最后一包 EOM=1。

我当初最大的困惑是："EID 和 I2C 地址怎么对应？" 答案在 MCTP over SMBus 的绑定规范里：目的 EID 并不直接等于 I2C 地址，而是通过一张"地址- EID 映射表"解析，这张表可以静态配置（写在 BMC 的设备树或配置文件里），也可以动态发现。对于入门，我们直接静态配置，省掉发现流程。

2.3 为什么选 SMBus 绑定而不是 PCIe VDM

MCTP 支持多种传输绑定，常见的有 SMBus/I2C、PCIe VDM、串口、USB。Jetson Nano 上最现实的是 SMBus，理由很直接：Jetson Nano 的 40-pin 排针上有现成的 I2C 控制器（I2C-1，对应引脚 3/5 是 SDA/SCL），电平 3.3V，和大多数交换芯片的 SMBus 管理接口电平一致，一根杜邦线加两个上拉电阻就能接起来。PCIe VDM 需要设备工作在 PCIe 配置空间上下文里，Jetson Nano 作为 host 去模拟 BMC 发 VDM，软件栈复杂得多，不适合入门。

这里有个容易被忽略的细节：SMBus 和 I2C 不完全是一回事。SMBus 在 I2C 基础上加了超时、加了 PEC（Packet Error Code，包错误校验），时序要求更严。MCTP over SMBus 规范里用的是 SMBus 的块写/块读（Block Write / Block Read），带 PEC 校验。但很多交换芯片的 SMBus 实现是"宽容模式"，不带 PEC 也认。实操时我的建议是：先用不带 PEC 的方式打通，能收发了再开 PEC 验证，否则一开始就被校验错误挡住，根本分不清是时序问题还是校验算法问题。

注意：Jetson Nano 的 I2C-1 默认时钟是 100kHz。交换芯片的 SMBus 管理接口通常支持 100kHz 和 400kHz，但上电初始化阶段很多芯片锁在 100kHz，贸然提到 400kHz 会出现间歇性 NAK。入门阶段老老实实 100kHz。

3. 硬件接线与软件环境准备：把地基打牢

3.1 物理连接：四根线之外的三个坑

接线本身不复杂：Jetson Nano 的 SDA（pin 3）、SCL（pin 5）、GND（pin 6 或 9）三根线接到交换芯片评估板的 SMBus 管理口对应引脚。但真正动手时，坑集中在三个地方。

第一个坑是上拉电阻。Jetson Nano 的 I2C-1 内部已经有 1.8kΩ 左右的上拉（接到 3.3V），而交换芯片评估板上通常也有自己的上拉。两边并联后阻值变成 900Ω 上下，对 100kHz 来说完全没问题，但如果你的板子远端走线很长，或者评估板的上拉是 10kΩ 的弱上拉，就会出现上升沿变缓、波形圆角，表现为随机 NAK。我一般会先用示波器看一眼 SCL 上升时间，超过 1μs 就要考虑调整。最稳妥的做法是只保留一侧的上拉，把另一侧的跳线帽拔掉。

第二个坑是共地与电平。Jetson Nano 是 3.3V 逻辑，绝大多数交换芯片的 SMBus 管理口也是 3.3V，但有些评估板的管理口做了电平转换，实际是 1.8V 或者需要外部 reference。接之前一定要拿万用表量一下管理口的 VDD 参考，别想当然。共地更不能省，只接 SDA/SCL 不接 GND，通信能"偶尔成功"，那种玄学故障最难查。

第三个坑是地址冲突。交换芯片的 SMBus 管理地址通常由硬件 strap 引脚决定，常见的是 0x64、0x65 这类 7 位地址（有的手册写 8 位形式 0xC8/0xCA，注意区分）。上电后用i2cdetect -y -r 1扫一遍，能扫到就说明物理层通了。扫不到先别怀疑芯片，先怀疑接线和上拉。

# 确认 Jetson Nano 上的 I2C 总线编号 i2cdetect -l # 扫描 I2C-1 上的设备（-r 用 SMBus 读方式，兼容性更好） sudo i2cdetect -y -r 1

正常输出里会出现类似64: 64 --这样的标记，说明 0x64 有设备响应。如果整行都是--，物理层就有问题，往后做任何协议层的事都是徒劳。

3.2 软件侧：内核配置与工具链

Jetson Nano 跑的是 Ubuntu 18.04（JetPack 4.x）或更新版本，内核里i2c-dev模块默认是加载的，/dev/i2c-1应该存在。先确认：

ls -l /dev/i2c-* # 若不存在，手动加载 sudo modprobe i2c-dev

除了i2c-tools，我建议装两个东西：

• libi2c-dev：后面如果要写 C 程序直接操作总线，靠它。
• 逻辑分析仪软件（比如开源的 sigrok/PulseView）：MCTP 报文出问题时，光看返回值没用，必须看波形。SMBus 块传输的时序有特征，能一眼看出是"地址 NAK"还是"数据 NAK"还是"PEC 错"。

如果你打算用 Python 快速验证，smbus2这个库比自己拼 ioctl 舒服得多：

pip3 install smbus2

需要说明的是，Linux 内核从 5.x 开始已经有一个MCTP 子系统（drivers/net/mctp），支持 MCTP over serial 和部分传输绑定，也提供了mctp命令行工具。但它在 SMBus 绑定上的支持并不完整，尤其是"模拟 BMC 主动发起"这条路径，很多版本还要配合特定的硬件。入门阶段我不建议直接上内核子系统，因为你会在"内核模块没编进去""设备树没配"这类问题上耗掉大量时间，而协议本身还没搞明白。用用户态程序直接拼字节流，虽然土，但每一步都看得见。

提示：Jetson Nano 的 I2C-1 上可能还挂着板载的摄像头控制或其他外设，扫描时看到 0x10、0x3c 之类的地址不要慌，那不是你的目标设备。

4. 报文格式拆解：一个字节一个字节地对

4.1 MCTP over SMBus 的封装结构

这一节必须掰碎了讲，因为90% 的入门失败都发生在这里：报文拼错一个字节，对端直接沉默，还不给你任何错误码。

MCTP over SMBus 的一次传输，从 I2C 层面看是"向目标地址写一串字节"，这串字节的结构如下：

看这张表你就明白为什么我说"裸 I2C 不够用"了：光是"这条消息给谁、谁发的、是不是第一片、要不要回复"这几个语义，就占了 5 个字节的头。而且这些头字节是协议规定死的，不是随便约定。

第 8 个字节（SOM/EOM/Tag/TO）值得单独讲。它的位定义是：

• bit 7：SOM（1 表示消息第一片）
• bit 6：EOM（1 表示消息最后一片）
• bit 5-4：Tag（0~3，用来标识本次事务）
• bit 3：TO（Tag Owner，1 表示发起方拥有这个 Tag）
• bit 2-0：保留

所以一条完整的单包请求消息（不分片），这个字节通常是0xC8（SOM=1, EOM=1, Tag=0, TO=1）。这个值我第一次拼的时候写成了0xC0，忘了 TO 位，结果对端认为这是一条"响应"，直接丢弃。这种错误没有任何日志，只能靠逐字节比对规范。

4.2 控制类消息：先做能力发现

所有 MCTP 端点必须实现控制类消息（Message Type 0x00）。控制类里面最基础的是Get Endpoint ID（命令码 0x02），用来确认"你在线吗、你的 EID 是多少、你支持什么消息类型"。这是最好的第一个测试报文，因为它的响应内容固定、容易验证。

请求负载只有一个字节：命令码0x02。完整发出去的字节流（假设目标 I2C 地址 0x64，本端源地址 0x20，目的 EID 0x09，源 EID 0x08）是：

[0x64] [0x0F] [0x05] [0x20] [0x00] [0x10] [0x09] [0x08] [0xC8] [0x00] [0x02]

拆解一下：字节计数 0x05 表示后面有 5 个数据字节（从源从机地址算起其实是 7 个，这里不同实现的计数口径有差异，这是最容易踩的坑之一，见 4.3 节）；版本 0x10；目的 0x09；源 0x08；标志位 0xC8；消息类型 0x00；命令 0x02。

发送用i2ctransfer最直观：

# 向 0x64 写入 MCTP 请求，注意第一个字节是命令 0x0F sudo i2ctransfer -y 1 w11@0x64 0x0F 0x05 0x20 0x00 0x10 0x09 0x08 0xC8 0x00 0x02

如果对端正常，接下来的响应需要读回来。SMBus 块读的形式是：

# 先写命令 0x0F，再读，长度按响应预期填 sudo i2ctransfer -y 1 w1@0x64 0x0F r12

响应字节流的期望结构是：

[字节计数] [源从机地址=0x64] [0x00] [0x10] [0x08] [0x09] [0xC8] [0x00] [0x02] [完成码] [EID] [类型数...] ...

其中完成码 0x00 表示成功，紧跟着一个字节是它自己的 EID，之后是一组"支持的消息类型"列表。看到0x00 0x09这样的组合，基本就可以确定链路通了。

4.3 那个让人抓狂的字节计数

我必须单独用一段说这个。SMBus 块传输的字节计数口径，在不同文档里定义不一致，有的把"源从机地址 + 保留字节 + MCTP 头 + 负载"全算进去，有的只算 MCTP 头之后的部分。博通的手册和 MCTP 绑定规范在某些版本上就存在这种表述差异。

实操中的判断方法很土但有效：先按规范的标准算法填，不通就 ±1 试。具体来说，如果对端完全没响应（连 NAK 都没有，就是读回全 0xFF），通常是计数偏大导致 SMBus 控制器发不出完整的 STOP；如果对端 NAK，通常是计数偏小导致数据被截断。我遇到过一次，卡了整整一个下午，最后发现是计数少算了保留字节，差一个数。

实操心得：把每次尝试的完整字节流（含计数）记在本子上，成功的那一组用红笔圈出来。MCTP 调试极容易在多次微调后失去参照，记流水账比任何调试工具都管用。

5. 从零跑通一次完整交互：分步实操记录

5.1 第一步：确认总线和设备在位

这一步看着废话，但请真的执行。我见过太多人跳过这步，在后面花了三小时排查协议，最后发现是杜邦线松了。

# 列出所有 I2C 适配器 i2cdetect -l # 期望看到 i2c-1 i2c Tegra I2C adapter I2C adapter # 扫描 sudo i2cdetect -y -r 1

如果目标地址出现，进入下一步；如果没有，按这个顺序排查：万用表量 SDA/SCL 静态电平（都应该是 3.3V 高电平）、量 GND 是否真的连通、换个地址再扫（可能是 strap 配置不同）、示波器看有没有时钟输出。

这里补充一个容易被忽略的点：有些交换芯片的 SMBus 管理口需要先释放复位。评估板上通常有独立的复位按钮或跳线，芯片处于复位态时 SMBus 是不响应的。另外，部分芯片的管理接口使能依赖某个 strap 引脚或 EEPROM 配置，如果板子是从别处拆来的，配置可能不是默认值。这种情况下i2cdetect扫不到，但芯片本身是好的。

5.2 第二步：用 Get Endpoint ID 做握手

字节流前面已经给了，这里补上完整的收发脚本。用 Python 写比命令行更容易做重试和解析：

from smbus2 import SMBus, i2c_msg import time BUS = 1 TARGET = 0x64 SRC_ADDR = 0x20 # 本端在 SMBus 上的地址，需与芯片配置匹配 DST_EID = 0x09 SRC_EID = 0x08 def build_get_eid(): payload = [0x02] # 控制类命令：Get Endpoint ID mctp = [0x10, DST_EID, SRC_EID, 0xC8, 0x00] + payload body = [SRC_ADDR, 0x00] + mctp byte_count = len(body) return [0x0F, byte_count] + body with SMBus(BUS) as bus: req = build_get_eid() print("TX:", " ".join(f"{b:02X}" for b in req)) wr = i2c_msg.write(TARGET, req) bus.i2c_rdwr(wr) time.sleep(0.05) # 读回，先给一个足够大的缓冲区 rd = i2c_msg.read(TARGET, 32) bus.i2c_rdwr(rd) data = list(rd) print("RX:", " ".join(f"{b:02X}" for b in data))

几个关键点解释一下。SRC_ADDR这个字节很容易被当成"随便填"，但实际上对端可能会校验它，要求它等于本端在 SMBus 上的从机地址，或者在允许范围内。入门时如果不知道填什么，可以先填0x20这类常用值试，不通再查芯片手册的"BMC 地址约定"。0xC8里的 TO 位设为 1，表示这是请求。读取时缓冲区给 32 字节是保守做法，实际响应可能只有十几字节，多余的会读到 0xFF，解析时忽略即可。

如果收到的数据开头是0x00（完成码成功），后面跟着一个 EID 值，恭喜，链路通了。如果读回全0xFF，说明对端没响应，回到 5.1 查物理层，或者检查字节计数。如果读回有数据但完成码非 0，去查控制类命令的完成码定义表。

5.3 第三步：读交换芯片的 MCTP 能力集

Get Endpoint ID 的响应里，除了 EID 和完成码，后面还有一串"支持的消息类型"。这串数据的格式是：每个类型占一个字节，最高位表示是否支持该类型的特定版本，低 7 位是类型号。看到0x00说明支持控制类，看到0x01说明支持 PLDM，看到0x02说明支持 NC-SI over MCTP。

这一步的价值在于决定后续做什么。如果只有控制类，那这条通道只能做最基本的存活探测；如果有 PLDM，就可以尝试读传感器、读固件版本；如果有 NC-SI，说明这颗芯片的管理通道能承载网络控制命令。我建议第一次跑通时把返回的类型列表完整记录下来，作为基线。

def parse_get_eid_resp(data): # data[0] = byte count, data[1] = src addr, data[2] = 0x00, data[3] = 0x10 completion = data[8] eid = data[9] types = data[10:] print(f"completion=0x{completion:02X} eid=0x{eid:02X}") print("supported types:", [f"0x{t:02X}" for t in types])

5.4 第四步：用 Set Endpoint ID 配置本端身份

Get 通了之后，规范上还建议做一次Set Endpoint ID（命令码 0x01），把本端的 EID 显式写进去，同时可以设置一些行为标志。这一步在真实 BMC 上是启动流程的一部分，目的是让双方对"我叫什么"达成一致，避免依赖默认值。

请求负载的结构大致是：命令码 0x01、操作类型（设置/强制）、EID 值。具体字段顺序各版本规范略有差异，以你手上芯片的手册为准。我在这里踩过的坑是：以为 Set 的负载和 Get 一样只有一个字节，结果多写两个字节导致对端把后续数据当成了新消息的开头，行为诡异。

注意：Set Endpoint ID 会改变端点的寻址状态，如果设错了，后面所有发往该 EID 的消息都会石沉大海，而 Get 仍然能通（因为 Get 用的是物理地址寻址）。调试时如果发现"Get 正常但别的命令都不通"，优先怀疑这里。

6. 踩过的坑与排查速查表

6.1 六类典型故障的定位路径

MCTP 调试的难受之处在于错误信息极度贫乏：对端要么沉默，要么 NAK，要么回一个你不认识的完成码。所以排查必须自下而上，一层一层排除。下面这张表是我自己整理并反复用到的，按"从物理层往上"的顺序排列。

这张表里最值得展开的是"首包能通，后续全失败"。MCTP 用 Tag + TO 做事务关联，规则是：发起方发请求时 TO=1，响应方回响应时 TO=0，且 Tag 必须与请求一致。如果本方在发下一条请求时没有正确切换 Tag（比如一直用 Tag=0），或者对端的响应被误判成请求，事务状态机就会错乱。表现出来就是"第一条好好的，第二条开始就不对了"。解决方法是把 Tag 做成递增计数器，0~3 循环，并且严格区分收发的 TO 位。

6.2 逻辑分析仪到底该看什么

很多人买了逻辑分析仪但不知道怎么用来看 MCTP。实际上你只需要关注四个特征点。

第一，START 之后的第一个字节是不是目标地址 + 写位。如果是，说明寻址正确。第二，有没有 ACK。每个字节后第 9 个时钟周期，SDA 被拉低就是 ACK。如果地址字节后就 NAK，问题在地址。第三，数据段长度是否符合字节计数。数一下实际发出的字节数，和你在代码里填的 count 对比。第四，STOP 是否正常出现。如果 STOP 缺失或者时序异常，SMBus 控制器可能判定传输失败。

我用 sigrok 的 I2C 解码器时，习惯把采样率设到 1MHz 以上（100kHz 总线至少 10 倍采样），否则解码容易丢位。解码出来的字节流和代码里的 TX 数组一对比，问题立刻现形——代码拼错和总线发错是两回事，逻辑分析仪能帮你把这两者分开。

6.3 三个容易被文档带偏的细节

第一个是"源地址"到底填什么。很多入门文档直接说"随便填个 0x20"，但 MCTP over SMBus 绑定规范里，这个字段是发起方的 SMBus 从机地址，理论上应该是本端在总线上的真实地址。Jetson Nano 作为 I2C 主设备时，严格说没有从机地址，但为了协议完整性必须填一个。实操上大多数芯片不校验这个字段，但个别严格的实现会。如果遇到莫名失败，把它改成和芯片手册里"BMC 默认地址"一致试试。

第二个是 PEC 的开关。前面提过，SMBus 块传输可以带 PEC。MCTP 绑定规范推荐带，但实现上很多芯片默认不开。开 PEC 之后，最后一个字节是前面所有字节的 CRC-8（多项式 0x07，初值 0x00）。如果开了 PEC 但算错，对端会直接 NAK，而且不会告诉你"是 PEC 错"。所以入门先关，通了再开，开了不通就先怀疑 CRC 算法。

第三个是"消息类型"和"命令码"的层级。头里的消息类型字节（0x00 控制类）和负载里的第一个字节（0x02 Get Endpoint ID）是两个层级的东西，前者决定由哪个协议处理器接管，后者是具体命令。我曾把命令码写到了消息类型的位置，对端把它当成一个不认识的协议类型，静默丢弃。

提示：调试期间建议在代码里加一个"十六进制完整打印 + 时间戳"的日志，把所有 TX/RX 落盘。MCTP 的问题往往在几十次尝试之后才显形，没有日志根本回溯不了。

7. 从模拟到落地：这套东西的延展空间

跑通 Get Endpoint ID 只是起点，但这个起点的价值比看起来大。真实的企业级系统里，BMC 与交换芯片之间的管理通道承载的东西很多：上电时序协调、固件版本查询与更新、温度与功耗监控、故障事件上报。这些在上层看是 PLDM 或厂商私有命令，但底下全都走 MCTP。你在 Jetson Nano 上把这层摸透了，换到真实 BMC 平台上，剩下的只是 SDK 接口差异。

如果要把这个模拟环境做得更接近真实，我认为有三个方向值得投入。一是把用户态程序改成常驻服务，实现请求队列、超时重试、Tag 管理，模拟 BMC 的 MCTP 守护进程行为。二是补上分片逻辑，故意发一条超过单包长度的消息，观察 SOM/EOM 的置位和重组过程，这是实际项目里最容易出 bug 的地方。三是接上 PLDM，用控制类通道先协商能力，再发 PLDM 的 Get Version 或 Get Sensor Reading，把整条协议栈串起来。

有一个经验我想单独说：别急着上内核的 MCTP 子系统。我见过不少人在 bring-up 阶段就想去配mctp网络设备、写 systemd 单元，结果设备树里 I2C 节点的mctp-controller属性、地址映射表、绑定驱动的匹配规则，任何一个不对都卡住，而且报错信息晦涩。先用手写字节流把协议语义搞明白，等你知道每个字节为什么是这个值，再去用现成的框架，效率会高得多。框架是用来省力的，不是用来替你理解协议的。

最后提一句硬件层面的观察。Jetson Nano 的 I2C-1 在长时间高频读写后偶尔会出现控制器忙状态，表现为i2c_rdwr返回EAGAIN。做长时间稳定性测试时，加一个几百毫秒的重试间隔就能避开。另外，杜邦线做 SMBus 连接超过 20cm 就不太可靠了，如果评估板和 Nano 离得远，宁可做一块小的转接板，也别用长排线硬拉——那些"跑一天挂一次"的玄学问题，八成出在线材上。