IIC通信卡死的两种情况和解决方案

本文主要记录了两例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(日系),由于推出时间比较早,且车规品迭代慢,因此没有集成总线时钟滤波器特性(滤除时钟线上的扰动),而当前消费级同类产品,已经迭代支持。后边新出的车规产品,也是支持这个特性的。(没错,选型踩坑了,而且已知其他用户也遇到类似故障了)

软件增加优化措施:

  1. 当SOC 发现某模块无法获取IIC通信时,将控制该模块电源重启,最多操作3次;
  2. 如果还存在通信问题,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特定条件下拉低总线

  1. IIC总线发9个CLK重启总线;
  2. IMU选型时注意了解其是否支持CLK 滤波特性。

IIC总线其他Device可以正常通信,只有IMU无法通信

IMU未知故障

  1. 优化IMU的休眠和初始化流程;
  2. 软件兜底,给IMU模块断电重启。(需要硬件支持电源开关)

任何IIC器件,包括不限于IMU/RTC/APPLE IC等,强烈建议硬件预留开关,否则,软件可能没法给你兜底,只能改版了。

IIC(Inter-Integrated Circuit)是一种广泛使用的串行通信协议,用于短距离数据传输。当我们在调试或设计基于IIC总线的系统时,“模拟IIC卡死”通常是指通过人为操作让IIC总线进入一种错误状态,以便测试设备如何处理这种异常情况。 ### 什么是“模拟 IIC 卡死”? 在实际应用中,由于硬件故障、软件问题或其他原因,可能会导致IIC总线发生“卡死”。所谓卡死,指的就是SCL(时钟信号线)SDA(数据信号线)的状态被锁定在一个特定值上无法正常切换。例如: 1. **SCL 被拉低**:主机尝试发送新的时钟脉冲失败,从机也无法响应; 2. **SDA 被拉低**:可能是某个器件未能释放SDA线而导致整个通讯中断; 为了验证系统的健壮性容错能力,在开发阶段可以主动创建类似场景——即所谓的“模拟卡死”。 --- #### 实现步骤: 以下是几种常见的模拟方法及注意事项: 1. **直接控制 GPIO 引脚** - 使用微控制器将连接到 SDA 或者 SCL 的GPIO设置成输出模式,并强制将其电平置0。 ```c // 假设使用的是 STM32 系列单片机 HAL_GPIO_WritePin(SDA_PORT, SDA_PIN, GPIO_PIN_RESET); // 拉低SDA ``` 2. **外部开关电路** - 添加一个由程序驱动的MOSFET晶体管等元件构成的小型开关网络至目标线路之间,利用它切断或者接地指定的数据/时钟路径。 3. **修改固件逻辑** - 修改现有主控端代码使之故意违反正常的握手规则造成阻塞效应。比如永远保持ACK位不变等极端措施。 4. **特殊工具辅助** - 利用专业级集成电路分析仪(如Bus Pirate),手动调整配置达到预期效果。 以上每种技术都有其优缺点,开发者应根据自身项目需求选择最合适的方案实施测试工作。 --- ### 注意事项: - 测试完成后记得恢复所有更改过的设置以防影响后续正常使用; - 应该记录每次试验过程及其结果方便后期改进优化算法应对策略.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值