广告

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

2014-10-15 阅读:
头痛医头脚痛医脚,只治得了疼,却治不了病。最近公司有一款新版硬件,在测试时发现原有的I2C通信测试程序运行失败,从I2C从设备RX8025中无法读取到数据 ……

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是满足要求的。也就是说在此处增加延时,并不能真正解决问题。

第2页:设计也如此:头痛医头脚痛医脚,只治得了疼却治不了病

第3页:技术大牛轻松解答 可能有两个问题引起

第4页:博主答网友疑问

{pagination}

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

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

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

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

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

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

第3页:技术大牛轻松解答 可能有两个问题引起

第4页:博主答网友疑问

{pagination}

王久东 NOP_WANG

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

1:是I2C的负载电容出现了问题(400K不行,200K可以),可以适当的减小I2C的上拉电阻,

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

ZukunftNetz

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

star666

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

昌海科技

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

向往但意

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

xujian2000

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

第4页:博主答网友疑问

{pagination}

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

catch

评论:

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

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

catch

评论:

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

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

catch

评论:

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

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

catch

评论:

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

您可能感兴趣的文章
相关推荐
    广告
    近期热点
    广告
    广告
    可能感兴趣的话题
    广告
    广告
    向右滑动:上一篇 向左滑动:下一篇 我知道了