我们最近就经济型I3C协议分析仪和一个从事NVMe SSD的客户做了现场技术交流，先从设备连接和软件基础操作开始，再到多通道I³C配置、采样/存储、触发、Trace查看、CSV导出、现场抓包异常、CRC/阈值/毛刺过滤、MCTP over I³C支持边界、试用和采购评估。当然，本次讨论重点集中在I³C/SMBus等低速协议采集解码、复合触发、长时间存储、CRC异常排查和后续样机试用安排上。可能对这方面有兴趣的朋友了解业内I3C协议问题诊断有一定的帮助，特此分享出来供大家参阅。

I³C抓包不是“能解码”就够了：一次现场Demo看清低速协议调试的真实门槛

—— I³C协议分析仪现场技术交流记录

很多工程师一听“协议分析仪”，第一反应可能是：能不能抓包？能不能解码？能不能导出CSV？

但真正到了研发现场，问题往往没有这么简单。尤其是I³C、SMBus、MCTP over I³C这类低速管理总线协议，表面看速率不高，实际调试起来却很容易卡在一些细节上：电压阈值到底设多少？一组线能不能变成多组协议通道？长时间跑机时数据存哪里？触发条件能不能精确到某个地址、命令、错误或时间窗口？CRC错误到底是协议问题，还是信号质量问题？软件解码出来的结果，是否真实反映了链路本身？

2026年6月17日上午，我们和客户团队做了一场协议分析仪技术交流，现场由Emily演示一款逻辑分析与协议分析二合一的工具。整场交流从设备接线、软件设置讲起，随后展示I³C协议解析、通道配置、触发、保存和导出功能，并在客户真实环境上做了抓包验证。现场也暴露出一些非常典型的问题，比如CRC错误、阈值设置不匹配、毛刺过滤对解码结果的影响，以及MCTP over I³C上层协议解析能力还需要进一步确认。

下面按照现场交流顺序，把这次Demo做一个完整梳理。

一、先从一个很基础的问题开始：这台设备到底怎么接？

会议开始时，大家先做了简单的场地确认、投屏和设备准备。Emily先说明，这次演示不会直接从复杂场景切入，而是先把基础操作流程跑一遍，让客户先知道这台设备如何连接、如何配置、如何开始抓包。

现场使用的是一个普通开发板，原计划通过开发板上的简单命令读取温度传感器，演示I³C或类似低速总线通信的基础抓取流程。设备本体比较小，可以理解为一个逻辑分析仪和协议分析仪的组合体。它一端通过一根线连接电脑，另一端通过多根引线接到被测板上的信号线上。

线束中黄色线是地线，蓝色线可以作为信号线使用。具体哪根线接clock、哪根线接data，并不是硬件固定死的，而是在软件里定义。这个设计对研发现场很实用，因为不同板卡、不同测试点、不同工程师接线习惯可能都不一样，如果每个pin都有固定用途，反而会增加使用成本。

从一开始客户就关心一个实际问题：它是不是只能抓一路I³C？答案是否定的。只要通道数量足够，一台设备可以同时配置多组I³C，例如0-1作为一组，2-3作为另一组。也可以把不同低速协议混在一起抓。也就是说，它不是“一个接口对应一个协议”，而是软件定义通道，硬件线束提供多路数字采集能力。

这也是这类低速协议分析仪的一个重要价值：很多板卡上不止一组管理总线，可能同时有I³C、I²C、SMBus、EEPROM访问、板级管理信号等。如果只能抓一路，现场调试效率会大打折扣。

二、软件和固件：客户关心的不只是能不能装，还关心后续怎么升级

设备接上之前，客户先问了软件授权和升级问题。

Emily解释，这类产品主要通过PC端软件控制，软件随仪器提供，并没有复杂的license绑定概念。客户也特别确认，如果团队里多位工程师轮流使用，软件能否安装到不同电脑上。从现场反馈看，这个问题不是限制点。

固件方面，客户也问到后续升级如何处理。Emily的解释比较务实：这台设备不像高速协议分析仪那样频繁涉及复杂协议栈和固件升级，更多是成熟低速协议工具，日常使用主要依靠软件。后续如果有软件或功能更新，可以提供给客户，但整体升级频率不会像PCIe/CXL这类高速协议分析仪那么高。

这段交流其实反映了客户对工具落地的典型顾虑：买设备不是只看第一次Demo能不能跑，还要看后续软件是否好维护，团队使用是否方便，是否会被某台电脑、某个license或某个复杂升级流程卡住。

三、通道配置：所有pin都可以自由定义

进入软件后，Emily首先演示了如何新增协议分析通道。

在软件里，可以选择协议类型，比如I³C，然后指定哪根线是clock，哪根线是data。每根物理引线本身没有固定角色，都是在软件中分配。客户问到是否可以同时添加多组I³C，现场演示说明是可以的：比如第一组使用0和1，第二组使用2和3；如果还有更多组，只要通道数量足够，也可以继续添加。

客户还问到，是否可以混合不同协议。Emily确认，这类低速协议可以混合配置。也就是说，同一台设备上可以同时放多个协议解码通道，每新增一个协议通道，界面上就会多一组对应的数字波形和协议解析结果。

这个功能对真实研发环境非常重要。很多时候，工程师不是只看某一条I³C总线，而是想同时观察某个事件发生前后，多个管理总线之间是否存在关联。例如某个设备状态改变后，主控是否访问了某个地址；某条SMBus命令后，另一条I³C总线上是否出现了异常响应。这种跨通道同步观察，是普通单路抓包工具很难替代的。

四、电压阈值：低速协议也不能忽略“物理层”

很快，客户把问题拉到了电压阈值。

对于逻辑分析仪来说，最关键的一步就是判断某个电压到底算0还是算1。客户问，阈值能不能调，最低支持多少。Emily在软件里说明，这个逻辑阈值可以设置，现场提到最低大约可以到0.1V，具体值可以再验证。

这个问题看起来很基础，但后面现场抓包时证明它非常关键。客户板卡上可能有1.2V、1.8V、3.3V等不同电平。如果阈值设错，软件看到的数字波形就可能和真实信号不一致，进而导致协议解码错误、CRC错误甚至误判链路异常。

也就是说，低速协议不是只看“协议层”。如果物理层阈值、电平、毛刺、边沿质量没有处理好，再好的解码器也可能给出错误结果。

五、采样率和长时间抓取：内存不是唯一瓶颈

客户随后问到采样率和存储方式。

这台设备内部有一定本地内存，但并不是无限大。Emily解释，实际长时间抓取时，可以选择把数据实时传到PC端，甚至存到外部SSD，而不是完全依赖设备内部内存。这样一来，长时间捕获就更多受电脑内存、硬盘容量和数据写入能力影响。

客户的典型场景是：设备挂在那里跑很久，异常可能一天才出现一次，工程师希望事后回来查看。对于这种场景，如果只靠设备内部内存，很容易被覆盖或抓不全。因此客户特别关心，数据写满后是停止、报错还是循环覆盖。现场并没有把所有边界细节完全确认清楚，但基本思路是：如果选择流式保存到PC或外部存储，就可以突破单纯硬件内存的限制。

Emily也提醒，模拟通道的数据量会非常大。她举例说，一个很短的简单抓取，如果保存模拟数据，可能就会生成几个GB的文件。因此她建议：如果客户主要看协议和数字逻辑，优先使用数字采集和协议解析；如果真正要看模拟信号质量，最好还是用专业示波器配合验证。

这点很实在。逻辑分析仪可以给你一个“够用”的模拟波形视图，但不能完全替代示波器。尤其当客户怀疑信号质量、毛刺、边沿、过冲、占空比异常时，专业示波器仍然是必要工具。

六、触发功能：真正有用的不是“开始抓”，而是“抓到问题那一刻”

接下来，Emily重点讲了触发功能。

触发的意义，是在长时间运行中捕捉某个特定事件。客户可能怀疑链路里偶尔出现某种错误，但不知道什么时候发生。如果没有触发，只能一直抓、一直存，最后在海量数据里慢慢找，非常低效。

软件提供基础触发和高级触发两类。

基础触发可以基于一些常见事件，例如起始帧、错误帧、特定协议事件等。

高级触发更灵活，可以通过state、counter和timer组合条件。现场解释说，最多可以配置7个state、2个counter和2个timer。state里可以定义某个事件、地址、命令码或相关字段条件；counter可以用于“出现多少次后再触发”；timer可以用于限制时间窗口，比如某个事件必须在10秒到50秒之间发生，或者两个事件之间的间隔必须落在某个范围内。

客户特别问到，能不能抓某个具体命令，并且命令里带有某些特定值。现场的回答是，这类组合条件可以在state里写，具体还需要客户后续按照实际协议字段尝试。

触发点的位置也可以设置。比如触发点放在1%附近，就相当于触发后才主要开始保留后续数据；如果放在99%附近，就更像是一直保留触发前数据，一旦错误出现马上停止；如果放在中间，则触发前后都保留一部分。

这个功能对现场调试非常关键。很多问题不是“我现在点开始就能复现”，而是“系统跑几小时才偶发一次”。能不能把触发条件写准确，往往直接决定了分析效率。

七、逻辑分析界面：波形、协议表、查找、统计、书签

由于现场开发板一开始没有顺利跑出预期数据，Emily先打开已有trace文件给客户看软件界面。

逻辑分析界面大致分几层：

上面是数字波形和部分模拟通道； 中间或下方是协议解码结果； 协议内容可以用表格方式展示； 右侧或工具栏可以做查找、统计、刷新、保存等操作。

客户可以在报告里筛选自己想看的字段，也可以用关键词查找某些内容。例如查找某个data值，软件会逐个定位相关记录。统计功能可以给出简单的最大值、最小值、平均值等信息。

书签功能也比较实用。用户可以在波形或协议位置打书签，例如用键盘字母标记K、J等，然后软件可以自动计算两个书签之间的时间间隔。这个功能虽然简单，但在调试时很常用，因为工程师经常需要比较两个事件之间的时间距离。

Emily也坦率说明，这个软件自带的分析功能是有的，但不一定完全满足客户所有深度分析需求。更现实的使用方式是：用设备把trace准确抓下来，再把协议解码结果导出成CSV，后续用Python或客户内部工具做进一步分析。

这句话很关键。对工程师来说，仪器软件不一定要解决所有数据分析问题，但至少要做到两件事：第一，原始捕获要可信；第二，导出的数据格式要可用。

八、CSV和私有格式：一个用于复盘，一个用于二次分析

保存功能也是客户关注点。

软件可以保存成私有格式，例如.sv文件，后续可以继续用原软件打开，保留波形、协议、书签等上下文。也可以导出CSV，CSV里的列基本对应软件中看到的协议表格字段。客户之前使用过类似工具，也确认他们关心的就是导出后字段是否清楚、是否便于后续脚本分析。

这里可以把两种格式理解为：

私有格式适合“复盘现场”，保留完整软件视图； CSV适合“二次分析”，方便导入Excel、Python或内部分析平台。

对于客户这种协议调试团队来说，CSV导出非常重要。因为真正复杂的问题往往不是靠人工翻几行协议表解决，而是要批量统计、筛选、关联多个字段、搜索异常模式，甚至和其他日志系统对齐时间轴。

九、逻辑分析和协议分析：侧重点不同，但边界并不绝对

随后，Emily又切到协议分析界面。

她解释，逻辑分析和协议分析的区别，更多是展示侧重点不同。逻辑分析界面更强调波形和底层信号，协议解析结果放在下方；协议分析界面则更强调协议表格，波形作为辅助显示在下面。

客户问到，逻辑分析文件和协议分析文件是否不同。Emily解释，在哪个页面保存，就保存成对应页面的格式。也就是说，软件内部把不同视图作为不同工作模式处理。

协议分析界面支持的协议类型比逻辑分析界面少一些，但对于客户当前I³C、SMBus等低速管理总线应用，基本覆盖了主要需求。只是如果涉及更高层的MCTP over I³C，就需要进一步确认支持深度。

十、MCTP over I³C：客户真正关心的是上层协议能不能解出来

客户很快提出了一个更深入的问题：底层I³C能解出来，那MCTP over I³C这种上层协议能不能进一步解析？

现场的回答比较谨慎。Emily表示，如果协议列表里没有显示，就说明当前软件可能不直接支持。她也提到，有些厂商或其他工具在I³C相关方面有规划，但不一定在抓取端完整支持。其实也有另外一个方案，即使用SerialTek PCIe Gen6协议分析仪，不过似乎大材小用。

这段讨论暴露出一个真实需求：客户不是只想看I³C的地址和基础读写，而是希望看到MCTP、MI等更上层语义。比如一条I³C传输里承载的是哪类MCTP消息、命令是什么、payload如何解释、checksum/CRC是否正确、是否符合某个设备管理流程。

现场后续实际测试也印证了这一点：在尝试解析MCTP over I³C相关内容时，软件似乎只能解出ADDRESS等底层字段，没有完整解析上层数据结构。因此后续需要厂商提供更多trace、帮助文档和配置示例，确认当前版本到底支持到哪一层。

这对采购决策影响很大。如果客户只是要便宜、灵活地抓底层I³C，设备可能已经够用；但如果客户核心需求是MCTP over I³C高层协议分析，就必须确认软件是否真正支持，或者能否通过CSV导出后由客户自己解析。

十一、现场接客户板卡：真正的问题从CRC错误开始

讲完软件界面后，大家把设备接到客户现场板卡上，开始实际抓取。

一开始抓到的数据并不多，随后重新连接和触发后，软件抓到了一些I³C通信内容。现场能看到类似read data structure、SDR等协议内容，但最后出现了CRC错误。

这个时候，大家的讨论从“功能展示”进入了真正调试状态。

客户和Emily开始怀疑：CRC错误到底是协议本身真的错了，还是分析仪因为阈值、电平、信号质量问题误判了某些bit？客户指出，当前板卡实际高电平可能是3.3V，而软件一开始阈值设在1.6V附近，需要确认匹配关系。

随后把阈值调整到更符合3.3V信号的设置，并进一步打开毛刺过滤功能。纪要里也记录了这一点：现场出现CRC校验错误，初步判断与信号毛刺和波形不规整有关；调整阈值并启用毛刺过滤后，CRC错误消失。

这段现场调试非常有价值。因为它说明一个协议分析仪是否好用，不仅取决于协议解码器，还取决于它如何处理真实世界里的不完美信号。

同一条总线，如果阈值不同、滤波不同、采样判断不同，最终解码结果可能完全不同。工程师必须知道：软件看到的CRC错，不一定等于链路真的传错了；也可能是仪器采样设置不合适。

十二、信号质量：协议分析仪不能完全替代示波器

CRC错误消失后，客户并没有完全放心，而是继续追问信号真实性。

客户希望设备能真实反映链路物理层状况，避免软件过滤或处理后“看起来没错”，但实际上掩盖了真实毛刺。现场也讨论到，最好用专业示波器对同一段信号进行对比验证，看分析仪捕获的数字结果和真实模拟波形是否一致。

这其实是一个非常专业、也非常必要的判断。

逻辑分析仪为了完成协议解码，必须把模拟信号转成数字0/1。这个过程中会涉及阈值、滤波、采样点、毛刺处理。如果它过于敏感，可能把毛刺当成真实bit；如果它过度过滤，又可能把真实问题抹掉。

因此，在客户这种研发场景下，正确用法不是让协议分析仪单独承担所有责任，而是：

协议分析仪负责长时间抓包、触发、解码、导出和协议层分析； 示波器负责关键时刻的物理层波形验证； 两者结合，才能判断问题到底来自协议、芯片、板级信号，还是仪器配置。

十三、试用安排

技术演示结束后，双方讨论试用和后续合作。

客户希望能拿到样机充分测试，最好试用时间长些。原因很简单：这类工具是否真的适合团队，不是看一次Demo就能决定的。需要接到真实板卡上，在不同场景下跑，验证长时间抓取、触发、CSV导出、MCTP解析、CRC误判、毛刺过滤、阈值设置等一系列实际问题。

厂商方面可以提供短期试用，但样机资源有限，初步讨论可能是一周。客户希望尽量延长，至少要有足够时间让不同工程师都试一遍。

后续将申请样机，并提供现有trace文件、MCTP/SMBus等协议资料、帮助文档和配置示例，包括准备MCTP over I³C trace、发送当前软件和抓取trace、安排样机申请、分享协议帮助文档、协调试用周期、验证毛刺过滤和不同电压设置下的解码准确性。

十四、经济型不是唯一理由，稳定抓包才是关键

会议最后，客户提到本次的核心抓包功能比较符合预期。

这句话对销售和产品定位都很重要。客户并不是单纯追求最低价，而是要综合判断：

是否能稳定抓到真实信号？ 解码是否准确？ 触发是否够灵活？ MCTP over I³C是否能满足需求？ 长时间抓取是否可靠？ 导出数据是否方便团队分析？ 多个工程师轮流使用是否方便？ 出现异常时，厂商是否能支持定位？

这款设备的优势很明显：价格相对非常经济；功能集成度高；通道配置灵活；支持逻辑分析、协议分析、触发、保存和导出；对I³C/SMBus等低速协议调试有一定吸引力。

但它要真正进入客户研发流程，还需要在几个方面证明自己：一是现场抓包稳定性；二是协议支持深度，尤其是MCTP over I³C；三是信号真实性验证；四是团队长期使用时的配置复用和数据管理便利性。

十五、这次交流真正说明了什么？

表面看，这是一场协议分析仪Demo；更深一层看，它其实反映了低速管理总线调试的真实复杂度。

I³C、SMBus这类协议速率不高，但它们在服务器、SSD、BMC、CXL/PCIe设备管理、板级控制和设备健康监控中越来越重要。很多系统问题并不是高速链路本身出错，而是管理总线上的某条命令、某次状态读取、某个MCTP消息或某次异常响应没有被正确处理。

这类问题的难点在于：

它们可能偶发； 它们可能跨多个低速通道； 它们可能与电平阈值和毛刺有关； 它们可能需要长时间跑机才能复现； 它们可能既有底层I³C问题，也有上层MCTP语义问题； 它们可能需要把协议trace、CSV、示波器波形和系统日志放在一起看。

所以，一台低速协议分析仪的价值，不只是“支持I³C”四个字，而是能不能在真实调试中帮工程师更快锁定问题。

结语：I³C调试，真正考验的是“信号、协议和现场经验”的组合

这次现场交流给人的最大感受是：低速协议调试并不低级，也不简单。

一开始只是接几根线、配置一个I³C通道，看起来很容易；但真正接到客户板卡上，马上就遇到CRC错误、阈值设置、3.3V电平匹配、毛刺过滤、MCTP上层解析、长时间抓取、trace导出和竞品对比等一系列真实问题。

这恰恰说明，工程师需要的不是一个只能“显示波形”的工具，也不是一个只能“解几行协议”的软件，而是一套能在真实研发现场工作的调试方法：

用灵活通道配置适配复杂板卡； 用长时间抓取等待偶发问题； 用复合触发精准停在错误现场； 用CSV导出进入自己的分析流程； 用示波器验证关键物理层波形； 用协议分析判断底层I³C和上层MCTP之间的边界； 最后用真实试用结果决定是否进入团队工具链。

从这个角度看，这次Demo最有价值的地方，不是它展示了多少菜单，而是它把客户真正关心的问题暴露出来了：抓到的数据准不准？解出来的协议够不够深？现场出现CRC错误时，工具能不能帮助我们判断问题来自哪里？

对于做服务器、SSD、BMC、PCIe/CXL设备管理和板级调试的工程师来说，这才是低速协议分析仪真正的门槛。

更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。

欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。