本文主要记录了两例IIC通信失败的典型案例,失效器件均为IMU,实际上其他使用IIC接口的Device也会存在类似情况。这里汇总实际项目开发过程中遇到的IIC的典型问题和对应的解决方案,希望可以给正在应用IIC的同学提供参考。
IMU作为GPS惯导实现的重要器件,也是哨兵模式功能实现的基础,在座舱、tBOX等控制器中大量应用。GPS惯导和哨兵模式本身并不是体验感非常明显的功能,甚至很多驾驶人实际不怎么使用。但由于其通信接口多为IIC通信,多器件共用总线,失效模式将可能导致整个总线无法通信,从而引起整车其他功能失效,引起客诉。
故障一:拉低IIC DATA线不释放,导致整个总线上的功能均失效。
实际案例:某项目在整车下线时发现两例功放无声音,debug发现IIC无法通信导致。
这路失效的IIC总线上同时挂了两路 AMP(受控电)、MIC(受控电)和IMU(常电,需求哨兵模式),故障发生时,为了确认是哪一路IIC器件故障,通过软件指令分别重启功放模块供电和MIC模块供电,以及SOC reboot故障依然无法恢复。同时读取故障时SOC的IIC口状态,发下DATA脚被拉低( 88PIN为data,89PIN为CLK)。整车掉电重启后功能恢复。
后续压测过程中复现了一次相同故障,故障发生时示波器显示DATA线低电平,IIC上所有Device无法通信。剪断IMU的IIC data线后IIC总线上其他Device通信恢复正常(压测前已将IMU的IIC串阻更改为飞线,方便验证)。由此实锤IMU器件出现了问题。
锁定了故障IC后,原厂介入分析,建议解决方案:SOC将IIC接口配置为IO口,往IIC上连发9个CLK重置总线。经验证确实可以复位总线,恢复通信。
另外,原厂介绍这款车规IMU(日系),由于推出时间比较早,且车规品迭代慢,因此没有集成总线时钟滤波器特性(滤除时钟线上的扰动),而当前消费级同类产品,已经迭代支持。后边新出的车规产品,也是支持这个特性的。(没错,选型踩坑了,而且已知其他用户也遇到类似故障了)
软件增加优化措施:
- 当SOC 发现某模块无法获取IIC通信时,将控制该模块电源重启,最多操作3次;
- 如果还存在通信问题,SOC将该IIC接口调整为IO口,往总线发送9个CLK时钟波形重置总线;
原本以为问题就此解决了,实际发现是想多了。加了优化措施以后确实故障概率降低了,但是偶有IMU 无法通信的失效件,且继续往下看。
故障二:IIC上其他Device功能正常,只有IMU无法通信。
这个问题其实困扰了我们很久,而且不像上一例可以很明确抓到故障波形,测了很多波形,也压测了很久,始终找不到根本原因,只能上一些优化措施,降低些失效概率。后续设计时进行规避。
波形测试:一开始我们怀疑IMU休眠流程时可能IIC通信发生了错误,导致其进入某种错误状态,无法再通过总线配置进入正常模式。通过压测台架复现,示波器获取故障前进入休眠时的波形,没有发现异常,正常ACK,正常结束符;上拉源也是在IIC通信完才掉的电。
原厂在review休眠和唤醒的代码时发现没有完全按照推荐来,软件对休眠逻辑和唤醒流程做了些优化(这块偷懒了,没去详细了解具体优化了啥,好像是调整了一些寄存器的读写先后顺序)。优化以后,故障概率似乎又减低了些。
但是依然偶有故障件怎么办呢?问题卡在这里了,突然一个同事灵光一现,终极解决方案来了。
由于这个项目采用的是SBC供电,SBC电源FS26产生3V3(常电),1V5给S32K324供电,同时这个3V3也直接给IMU供电,没有加开关。由于休眠时MCU需要支持唤醒功能,这个3V3电源没有掉电,我们就习惯称之为常电。惯性思维也没有想过这个常电能掉电(其他项目使用的都是普通的LDO或DCDC给MCU供电,没有用SBC电源)。同事突然想到这个是SBC电源,是否支持发生故障后SOC通知MCU,MCU通知SBC掉一下3V3电源然后重启?赶紧咨询下NXP,果然是可以的,使用SBC的LDT功能,具体流程如下。
这个项目由于使用了SBC常电能被关掉重启是幸运的,但是多数应用常电是无法关闭的。所以后续项目我们都给供常电的电源也加了一个可以关闭的开关,以便类似情况下有一个兜底方案。
经过IMU IIC这一系列折腾,总结如下。
故障表现 | 故障原因 | 解决方案 |
IIC Data线拉低,总线所有Device均无法通信 | IMU特定条件下拉低总线 |
|
IIC总线其他Device可以正常通信,只有IMU无法通信 | IMU未知故障 |
|
任何IIC器件,包括不限于IMU/RTC/APPLE IC等,强烈建议硬件预留开关,否则,软件可能没法给你兜底,只能改版了。