Communication protocol I2C subsystem Debug

There are two common I2C errors: I2C ACK error, I2C timeout

1. I2C ACK error

If the ACK signal is not received when it should be, the i2c controller will generate an ACK error interrupt to tell the i2c driver that an ACK error has occurred. Usually, this is a problem with the slave itself.

1. Check whether the device exists and whether the i2c bus number and device address are correct. The example is as follows: i2c number is 6, addr is 0x28:

 [ 31.092951 ][ xxx ] i2c i2c-6 : addr : 0x28 , ACK error

2. Check whether the device has been powered on and enabled, and whether it has been inited correctly.

3. Check if the i2c speed is compatible. If the speed is greater than the max speed supported by the device, it will also cause ACK Error. Reduce the speed. If it still works, it means it is a clk-related problem.

4. Check whether the i2c device signal level matches that of the AP.

5. GPIO check The following parts:

1. GPIO current drive capability.
2. Whether the GPIO working mode is I2C mode.
3. Whether the GPIO has an internal pull-up resistor.
4. GPIO default level state.

According to the i2c spec, NACK is normal in the following situations.

I2C Write

When the host sends data to the slave, the slave may or may not respond to the last byte of data, but the host can generate a stop condition in either case. If the host detects that the slave does not respond when sending data to the slave (even including the slave address), the transmission will be stopped in time.

I2C Read

When the host receives data from the slave, the host does not respond to the slave at the last byte of data, that is, NACK.

2. I2C timeout

When an I2C transmission times out, the kernel log will generally print something like this:

 [48.197718][xxx]i2c i2c-1: addr:0xa,transfer timeout

1. GPIO check the following parts.

1. GPIO current drive capability.
2. Whether the GPIO working mode is I2C mode.
3. Whether the GPIO has an internal pull-up resistor.
4. GPIO default level state.

2. Check the slave order.

1. The first slave that times out in the log.
2. A slave with power control and reset control.
3. other slaves.

After reproducing the problem, you can manually remove the corresponding peripherals to confirm which peripheral is holding the i2c bus. Then communicate with the supplier, debug the status of the IC, and figure out the reason why the i2c bus is being held.

3. i2c-tools

i2c-tools is also very useful. I wrote about this tool last time. Please refer to the following article:

​​Teach you how to use i2c-tools step by step. ​​

4. Frequently Asked Questions

1. The i2c addr of all peripherals on the same i2c bus must be different

(1) Conflict when registering the same address.

 [ 2.059184 ][ xxx ] i2c i2c-1 : Failed to register i2c client 24c02 at 0x51 ( -16 )
 [ 2.059189 ][ xxx ] i2c i2c-1 : Can 't create device at 0x51

The corresponding error code is -16.

 /kernel-5.10/include/uapi/asm-generic/errno-base.h ​ ​ ​ ​ ​ ​
 #define EPERM 1 /* Operation not permitted */
 #define ENOENT 2 /* No such file or directory */
 #define ESRCH 3 /* No such process */
 #define EINTR 4 /* Interrupted system call */
 #define EIO 5 /* I/O error */
 #define ENXIO 6 /* No such device or address */
 #define E2BIG 7 /* Argument list too long */
 #define ENOEXEC 8 /* Exec format error */
 #define EBADF 9 /* Bad file number */
 #define ECHILD 10 /* No child processes */
 #define EAGAIN 11 /* Try again */
 #define ENOMEM 12 /* Out of memory */
 #define EACCES 13 /* Permission denied */
 #define EFAULT 14 /* Bad address */
 #define ENOTBLK 15 /* Block device required */
 #define EBUSY 16 /* Device or resource busy */
 ......

You can execute ls /sys/bus/i2c/devices to check whether there is a peripheral with the same address registered under the corresponding i2c-1.

If -11, -EAGAIN is returned, it means the bus is busy or the bus lock cannot be obtained. If the bus is busy, please retry and wait, or check which device is sending all the time. If the bus lock cannot be obtained, please check whether i2c_transfer is called in an interrupt function or atomic context.

(2) Hidden i2c address, that is, the peripheral has multiple i2c addrs or the peripheral HW bug, resulting in i2c communication abnormalities.

Example: EEPROM registers address 0x50 on i2c-1, and although Type C registers address 0x60, it can also respond to 0x50. Type C pulls SDA low, resulting in a timeout.

debug method:

1. Confirm on the software whether the data and the corresponding driver are correct.
2. Remove peripherals one by one on the hardware to confirm which peripheral is causing the problem.

2. There are glitches on the ACK of the oscilloscope

After the slave generates an ACK response at the 9th clk, the glitch is generated when the master end is switched to control. This glitch will not affect the read and write timing of the I2C bus and does not need to be processed.

That is, the slave and master control bus switching interval, no one controls the bus, resulting in glitches.

3. Half high level

In the case of an external pull-up resistor, there is an enable internal pull-down resistor, resulting in a half-high level on the bus.

4. The level on the bus cannot be pulled to ground

1. When the master end sends data, the level cannot be pulled to the ground. You can increase the driving current or the pull-up resistor.
2. If the slave end cannot be pulled to ground, you can consult the supplier to see if the slave end drive current or pull-up resistor can be increased.

5. RK platform I2C debug

Derived from firefly.

 https://wiki.t-firefly.com/zh_CN/Firefly-RK3399/driver_i2c.html ​ ​ ​ ​ ​ ​ ​

I2C communication failed, log: "timeout, ipd: 0x00, state: 1" appears

Please check whether the hardware pull-up is powered.

Calling i2c_transfer returns a value of -6?

A return value of -6 indicates a NACK error, which means that the other device does not respond. This is usually a problem with the peripheral device. The following are common situations:

1. The I2C address is wrong. The solution is to measure the I2C waveform to confirm whether the I2C device address is wrong.
2. The I2C slave device is not in normal working state, for example, no power is supplied, wrong power-on sequence, etc.
3. If the timing does not meet the requirements of the I2C slave device, a Nack signal will also be generated.

What should be done when the peripheral device requires a stop signal instead of a repeat start signal in the middle of the read timing?

At this time, you need to call i2c_transfer twice, and split I2C read into two times. Modify as follows:

 static int i2c_read_bytes ( struct i2c_client * client , u8 cmd , u8 * data , u8 data_len ) { struct i2c_msg msgs [ 2 ];
 int ret ;
 u8 * buffer ;
 buffer = kzalloc ( data_len , GFP_KERNEL );
 if ( !buffer )
 return - ENOMEM ;
 msgs [ 0 ] .addr = client- > addr ;
 msgs [ 0 ] .flags = client- > flags ;
 msgs [ 0 ] .len = 1 ;
 msgs [ 0 ] .buf = & cmd ;
 ret = i2c_transfer ( client- > adapter , msgs , 1 );
 if ( ret < 0 ) {
 dev_err (& client- > adapter- > dev , "i2c read failed\n" );
 kfree ( buffer );
 return ret ;
 }
 msgs [ 1 ] .addr = client- > addr ;
 msgs [ 1 ] .flags = client- > flags | I2C_M_RD ;
 msgs [ 1 ] .len = data_len ;
 msgs [ 1 ] .buf = buffer ;
 ret = i2c_transfer ( client- > adapter , & msgs [ 1 ], 1 );
 if ( ret < 0 )
 dev_err (& client- > adapter- > dev , "i2c read failed\n" );
 else
 memcpy ( data , buffer , data_len );
 kfree ( buffer );
 return ret ;
 }

I believe the above I2C debug method can solve most of the problems for you. If it still doesn’t solve the problem, it is usually a chip problem or a bug in the original factory’s underlying code. You can seek support from the chip manufacturer.