关于Linux i2c调试心得(读数据时返回NACK的问题)

最近遇到一个i2c访问比较诧异的问题：

现象如下：

1. i2c上的设备是e2prom, e2prom的访问方式是block形式的(相当与1个block，对应一个i2c地址，一共有8个block,因此，用i2c tools工具去检测的时候，发现i2cdetect -r -y 5，检查的时候，会检查到8个地址，即从0x50-0x57)。 按照理解这其实就相当与挂了8个i2c设备

2. 使用i2cdump -f -y  5  0x50是发现dump的数据固定的地址显示XX，体现是，调试发现显示XX的意味这i2c read失败，read数据时使用的random read方式，即写地址+restart+读地址数据),量信号后发现CPU写完地址后，设备返回的是NACK。

3. 且上述现象时必现的，且每次都是固定地址。且都是有1110的寄存器地址有问题。如:0xe寄存器地址读一直有问题，且写完地址后，设备都是返回的NACK。

思路：

1. 怀疑i2cdump是不是有问题，用i2cget -f -y 5 0x50 0xe 发现仍然报i2c访问失败。

2. 怀疑i2c tool是不是有问题，自己写代码实现，仍然有问题

3. 使用i2cset -f -y 5 0x50 0xe 7 ,发现能成功，但是读不能成功

4. 对于i2cdump有数据寄存器读写，也是没有问题的，就是固定的地址不能访问，怀疑可能是CPU i2c controller驱动能力，不够，但是从信号上看，没有发现电压降低等现象，后来试着增大驱动能力，也是没有效果的

5. 量i2cget时，0xe的i2c信号，竟然量不出来信息，但是i2cdump能量出信号，最后发现是硬件用示波器不会量一次的i2c信号(奶奶的。。。，换了好几个硬件都没有量出来，只有一个女生后来会量，bsp调试的时候，一个好的硬件的重要性，这个量不出来的时候，当时硬件就一值说软件有问题)

6. 后来继续查看硬件上出问题的i2c总线和没有出问题的i2c总线的差异，后来发现，出问题的i2c总线上的e2prom, 和没有出问题的i2c总线上的e2prom,除了e2prom的厂商不一样外，出问题的i2c总线上中间会挂接了一个转接器，这个转接器的目的是为了避免信号干扰以及热插拔造成的问题。注意这里也体现了一个好的硬件的重要性，最初的时候，硬件告诉bsp，这个转接器对i2c信号没有任何影响，后来发现，其实是这个转接器对i2c信号是有要求的，CPU对接的其实是这个转接器，而不是对接的e2prom, 同时，这个转接器是不受CPU控制的，完全是硬件连接的，但是这个转接器，对i2c信号是有要求的，要求i2c的sda的hold time必须满足300ns的时间延时。

      后来量信号发现：在转接器前的i2c信号和在转接器后的i2c信号是差别的。这个差别就在信号明显变差，在转接器后面的sda hold time的时间明显比前面小很多，且时间很临界。后来查看CPU i2c controller手册以及device i2c 驱动代码，发现这个sda hold time可以增加，后来增加到300ns就没有问题。

这个问题的总结：

1. 确认i2c总线与设备之间是否由别的器件，总线是否过长

2. i2c信号的测量非常重要，以及对设备的理解也很重要(发现一个刚毕业的硬件和一个工作几年的硬件和一个工作十几年的硬件，差别还是很大的，这里的转接器的问题，就是那位工作十几年的硬件同事发现的，其它的硬件同事就只会说：与硬件没有关系，是软件的问题，奶奶的，我当时都想骂人了)

3. 如果中间有器件，量一下，中间器件前后信号是否有变化

4. i2c信号的时序，必须要对照好设备手册，如上升沿时间，下降沿时间，hold time等等，有很多，这个最好找有经验的硬件同事来帮忙分析。

5. 另外，关于这个sda hold time的时候配置问题，经过检查，有的CPU的i2c controller，软件是可配置的，但是有的CPU的i2c controller是没有这个配置的，此时，我们可以根据修改I2c的上拉电阻，或者下拉电容，可以一定程度的增加这个时间。如果实在不能，请避免使用这些对时间要特殊要求的器件。且后来发现，e2prom设备本身对sda hold time这个时间要求只要大于0即可，主要是中间转接器对i2c的sda hold time有300ns的要求。

6. 最后，i2c时序中i2c是在高电平采样的。