最近公司有一款新版硬件，在测试时发现原有的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。而这，需要的不只只是眼睛，还有思考。
头痛医头脚痛医脚，只治得了疼，却治不了病。
- 上一篇： 使用可靠的I2C代码
- 下一篇： Contiki的NETWORK层间数据传输流程
用户1406868 2014-10-16 09:58
用户1623276 2014-5-17 19:50
用户1623276 2014-5-17 19:49
用户1406868 2014-5-16 23:35
用户874192 2014-5-13 09:35
用户1406868 2014-5-8 13:23
1989tie_959541171 2014-5-8 09:31
1989tie_959541171 2014-5-8 09:27
1989tie_959541171 2014-5-8 09:23
1989tie_959541171 2014-5-8 09:21