每一笔I2C的访问都是随着设备互相之间的ACK后结束的,这就好像你和别人商量个事情,要等到别人答应了,这次对话才算结束;又或者你给别人寄一个包裹,一般要等到收件人收到东西后,给你回了电话,你才会认为东西送到了。
这里的“答应”和“回电话”就等于I2C里面的ACK,这一点在前面都已经反复叙述了,这里不再展开说明(可以戳文段开头的链接回顾哦)。
1.系统串口打印信息如下,表示I2C访问失败:
I2C slave device not found num1,addr 0xe2====i2c_send_command_to+scc_rommon send_status Failed.
I2C slave device not found num1,addr 0xe2====i2c_send_command_to+scc_rommon send_status Failed.
2.上图中我在ACK的位置坐了标注,细心的读者只要和下面这张正常的图一比较,就可以看出差别,在ACK的位置,SCL为High/SDA为Low,但是上图确刚刚好相反;
3.我们现在知道在第一个ACK的位置, Slave设备本来应该给出SDA=Low,为了更加清楚的分析问题,我们再来一张说明更多的图。
由前面的说明,我知道是Slave设备出了问题,那么到底出了什么问题呢?
我们先把最前面那张图的案例分析一下,可能有人已经注意到了图中有一个@-40C,对了,没错!就是我们的交换机放在温箱里面做高低温时,在零下-40C的时候发现的问题。
有人问-40度下,这波形怎么量到的啊?
这明显问到了关键点上,硬件工程师的辛苦就体现出来。首先要把I2C信号线和串口线分别从板子上焊接出来,再分别连到外面的示波器和电脑上,然后就苦逼地守着温箱,运气好的话很快就能复现问题,运气不好要折腾很久才能trigger到这个issue,真的是一把辛酸泪啊。
解决的问题过程更加复杂,而且并没有什么技术含量可言——说服Supply Chain的人认为是vendor的器件问题,让他们在芯片生产线做Screen的时候,从原来的泡-40/5分钟改为-45/20分钟,把没有margin的芯片筛选掉。这个和Supply chain以及vendor沟通的过程是痛苦的,大公司嘛,不说了,你们懂的……
现在我们知道了器件受环境影响会产生I2C不ACK的问题,下面这张图是另外一种情况,先故设迷局,一起看看下图中有什么问题?
我承认,这个真的不好发现,以前团队中的某工程师在调试一个Sony的IMX291 Sensor时,CPU通过I2C死活访问不了,最后把波形一点一点在示波器上触发下来看,还是看不出来,这就难怪,没有经验确实很难找。
1.Start
2.Master发device address
3.Master发 R/W为Write
4.Slave 回ACK
5.Master发寄存器地址,也叫Word Address
6.Slave 再回ACK
7.Master发要写的数据给Slave
8.Slave收到数据后回ACK
9.Master看到ACK后发Stop结束本次操作
1.Start
2.Master发device address
3.Master发 R/W为Write
4.Slave 回ACK
5.Master发寄存器地址,也叫Word Address
6.Slave收到后再回ACK
7.此时Slave内部的寄存器指针已经知道对应的寄存器地址
8.Master发start
9.Master再次发device address
10.Master 发R/W为Read
11.Slave发出ACK
12.Slave发数据给Slave
13.Master收到数据后发NAK给Slave
14.Master发stop结束本次读操作
所以上图的读操作一共有两个错误,为了防止读者烧脑,我直接标注出来吧:
不知道大家在前面阅读的时候有没有看出来呢?特别是第一个Start很容易漏掉,不是老司机一下子真心发现不了。
添加了这里漏掉的START和ACK后,我们的Sony Sensor终于可以访问了,所以时刻要注意ACK是否少了。
为了让大家清晰理解,这里给出一张完整的逻辑图,大家在理解时要注意和写操作做对比,然后一定要独立思考弄清楚为什么会有这样的差别?一直到自己彻底想明白了,以后独立解决问题的速度也就会变快。
最后我再给大家看一张图,请大家自行研究错在哪里?答案我们将在“第六宗罪”里面揭晓。
——END——