找问题主因 硬件改版引起的I2C异常

admin

catch博主自我简介提到自己正“从事物联网相关工作，走在电子的路上。”写的文章技术性特别强。这一篇《硬件改版引起的I2C异常》发表至今，高质量评论有22条。以下是博客原文：

最近公司有一款新版硬件，在测试时发现原有的I2C通信测试程序运行失败，从I2C从设备RX8025中无法读取到数据。使用示波器的时候，也无法在时钟线SCL上看到时钟信号。但是在测试数据线SDA的时候，偶尔能看到一些数据。如果使用示波器表笔点在测试的信号线上，有时能读到正确的数据；如果不这样做，几乎看不到正确的数据。开始怀疑是否是因为测试程序本身可靠性有问题，因为在一段时间测试后发现，这种现象随机性比较大。如果程序，没有初始化好硬件，或延时没做好，很容易造成这种随机性的问题。

于是，将软件可能的延时及初始化检查了一遍。找到了一处延时疑似有问题的地方。将这个地方的延迟增大2us后，测试竟然运行都通过了。在接下来的测试中，I2C读写正常。此时，找到I2C通信失败的原因了：I2C信号从写入结束发送STOP，到下一次开始读取从设备的Start时间间隔约为在3.7us，此时间偏小，导致通信不稳定，增加延迟可以解决问题。

在写完，上边的结论后，认为事情到此结束。

之后，分析了STM32的I2C主机通信时钟信号的参数，同时检查了程序中I2C的参数配置。发现不应该出现这样的情况。因为程序配置的I2C参数，使其运行在Fast mode此种模式下，Stop：Start的时间间隔最小为1.3us，而实际的3.7us是满足要求的。也就是说在此处增加延时，并不能真正解决问题。

在第二天的测试中，发现原来的解决方法确实存在问题。还是会有I2C通信失败的情况。再将原有测试程序中I2C的超时处理部分用#if注释掉（因为STM32库自带的I2C示例程序存在致使程序陷入while死循环的情况，而其优化解决方案使用了DMA+中断，感觉有些杀鸡用牛刀，不太合适。于是在其原有程序中做了超时处理，避免I2C通信失败陷入while死循环）。发现，程序运行正常。但是，如果加上超时处理，程序就无法正常运行。由此说明，并不是什么Stop：Start的时间问题。

于是将原有I2C测试程序（参数不变，带超时处理）在旧的硬件上运行，通信正常。

这里问题出来了，同样的程序，在旧的硬件中可以运行，在新的硬件上运行异常，这里边应该哪里有问题。于是，将原有的I2C通信速率400KHz的时钟降低到200KHZ，保留超时处理，在新的硬件版本上运行。发现运行正常，读取数据正常。

至此，于新版硬件的I2C通信问题，自认为是找到了：I2C的400KHz时钟速率在新版硬件上运行存在异常，调低时钟速率在新版硬件上运行（硬件优化后，或许继续使用原有的参数）。

由此问题解决过程中，发现：很容易将问题Q消失时，采用的方式M认为是问题出现的地方。可是往往，问题的真正原因R却躲在某个角落，为M替其顶罪感到开心，也为躲过了一场搜捕感到窃喜。下一次，他还会出来继续作乱。只有当真正将R绳之以法，才能根据解决问题Q。而这，需要的不只只是眼睛，还有思考。

头痛医头脚痛医脚，只治得了疼，却治不了病。

这样的问题，硬件首当其冲啊，根据现象描述有可能2个问题，

1：是I2C的负载电容出现了问题（400K不行，200K可以），可以适当的减小I2C的上拉电阻，

2：I2C的信号出现了过冲引起信号的完整性问题（示波器表笔点在测试的信号线上，有时能读到正确的数据），示波器的探头可以等效为一个小的电容，你可以试着在信号线上面并一个小的10PF左右的电容看下，问题有么有改善，但是总的原因还是硬件居多，要结合硬件设计和PCB走线综合分析。

ZukunftNetz

nop_wang的解释非常专业，学习了。但是从信号完整性的角度超过20M才会有si的问题吧，负载电容是对示波器接入后信号正常的一个很好的解释

star666

这个问题很正常，改动硬件后，走线可能变长，干扰会变大。所以以前的400K要降低到200K。对于通讯，频率越高对布线的要求就越高。解决办法通常是降低通讯速率，在通讯速率不呢降低的情况下，要请有经验的工程师进行改版布线。

昌海科技

咱也遇到过。不同厂家的片子参数是不一样的。虽然号称是400K，实际上以这样的速率运行是有问题的。

向往但意

是的，这是基本的东西。也是最实用的。呵呵

xujian2000

学习了，谢谢分享！但遗憾的是是否已经解决问题尚不知道，问题究竟是什么原因产生没有介绍。

@Frank1960: "将原有的I2C通信速率400KHz的时钟降低到200KHZ" 只是找到問題點，那後來呢？ 規格上要求還是要跑400KHz，後來是怎麼解決的？

catch

评论:

如果要求400KHz，肯定要继续找原因。这里I2C读取的数据量较小，相对于速度更要求系统工作的可靠型，保证系统长期稳定工作是重点。现在的做法，只是一个速度与稳定的balance。实现简单，达到高标准就要付出更多的努力。

@刀客: 感觉还是没有找到问题的根本原因，只找到了硬件上有差异，再深入一点就更完美了。

catch

评论:

问题只是从软件上暂时规避，问题已经反馈给硬件工程师，等待解决中。如果能找到本因，再更新到这里。

@skygrass123: 同一版程序在新旧两版硬件上的运行结果不一致，矛头就直接指向硬件差异了吧。 硬件差异未知情况下，尝试修改软件，至多是临时性的规避该问题。 原因终究是要查清楚的，否则不知道下一次会出现在什么地方。

catch

评论:

博客所描述的工作，就是将问题确认到是硬件还是软件。之后具体再分析。

@lzscan: 拿示波器看看波形怎么样。是不是有明显过冲，回勾什么的。个人觉得降频不是个最优解决方案。除非你改版后换芯片了。

catch

评论:

使用示波器观察过波形，不存在明显的过冲，信号正常。降频确实不是很好地方案，问题已经反馈给硬件工程师，等待结果中。