硬件改版引起的I2C异常

最近公司有一款新版硬件,在测试时发现原有的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。而这,需要的不只只是眼睛,还有思考。
头痛医头脚痛医脚,只治得了疼,却治不了病。

你可能感兴趣的:(其他)