I2C subsystem (IV): I2C debug

I2C There are two common mistakes ：I2C ACK error、I2C timeout

1、I2C ACK error

It should be received in ACK I didn't receive the signal ACK The signal ,i2c controller There will be a ACK error The interrupt , tell i2c driver It happened. ACK error. Usually it's slave Its own problems .

1、 Check device Whether there is ,i2c bus number and device address Whether it is right . Examples are as follows ：i2c number by 6,addr by 0x28：

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

2、 Check device Whether it has been powered on , And the right init

3、 Check i2c speed Whether it fits ,speed Greater than device Supported by max speed Can also cause ACK Error. Reduce speed , If it still works, it means clk Related issues .

4、 Check i2c device Whether the signal level is consistent with AP matching .

5、GPIO check The following sections

1. GPIO Current drive capability
2. GPIO Whether the working mode is I2C Pattern
3. GPIO Is there an internal pull-up resistor
4. GPIO Default level state

from i2c spec see , As follows NACK It's normal .

I2C read

When the host receives data from the slave , the last one Byte Data time , The master should not return to the slave , namely NACK.

2、I2C timeout

When I2C Transmission occurs timeout when , commonly kernel log There will be printing similar to the following ：

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

1、GPIO check The following sections

1. GPIO Current drive capability
2. GPIO Whether the working mode is I2C Pattern
3. GPIO Is there an internal pull-up resistor
4. GPIO Default level state

2、 screening slave The order

1. log The first one in timeout Of slave
2. Yes power Control and reset The control of the slave
3. other slave

After repeating the question , Corresponding peripherals can be removed manually , Confirm which peripheral will i2c bus Hold on , Then communicate with suppliers ,debug It's time to IC state , Clear up and hold i2c bus reason .

3、i2c-tools

i2c-tools It's fine too , You can baidu , A lot of tutorials .

4、 common problem

1、 Same article i2c bus On all peripherals i2c addr To be different

1） identical address Registration conflicts

[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 */
......

It can be executed ls /sys/bus/i2c/devices Check the corresponding i2c-1 Whether there is already the same registered address The peripherals of

The reason for the repetition ：

1. dts As defined in i2c device node , There are some driver Use traditional i2c_register_board_info Function to register i2c device.
2. dts Duplicate definition in .

return -11,—EAGAIN. Means the bus is busy , Or the bus lock cannot be applied . If the bus is busy , please retry wait for , Or check which device Has been sending . If the bus lock cannot be applied , Please check whether i2c_transfer.

2） Hidden i2c address, That is, there are multiple peripherals i2c addr Or peripherals HW bug, Lead to i2c Abnormal communication .

Example ：eeprom stay i2c-1 Registered. 0x50 Address , and type c Although registered to 0x60 Address , But yes 0x50 Can also produce a response ,type c Pull down SDA , thus timeout .

debug Method ：

1. Confirm the data and corresponding driver Whether it is right .
2. Remove peripherals from the hardware one by one , Confirm which peripheral caused .

2、 Oscilloscope ACK There are burrs in the place

slave In the 9 individual clk produce ACK After response , Switch to mater The burr generated during end to end control . This burr will not affect I2C Bus read / write timing , No need to deal with .

namely slave and master Control bus switching interval , No one controls the bus , The burrs .

3、 When the external pull-up resistor is connected , Yes enable Internal pull-down resistance , This leads to a half high level on the bus .

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

1. master When the terminal sends data, the level cannot be pulled to the ground , Drive current or pull-up resistance can be increased .
2. slave The end cannot be pulled to the ground , Consult the supplier to see if it can increase slave End drive current or pull-up resistance .

5、RK platform I2C debug

originate firefly

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

1、I2C Communication failure , appear log: “timeout, ipd: 0x00, state: 1”

Please check whether the hardware pull-up is powered .

2、 call i2c_transfer The return value is -6？

The return value is -6 Expressed as NACK error , That is, the other party's equipment has no response , This is usually a peripheral problem , There are several common situations ：

1. I2C Wrong address , The solution is to measure I2C wave form , Confirm if I2C Device address error ;
2. I2C slave The equipment is not in normal working condition , For example, no power supply , Wrong power on sequence, etc ;
3. Timing does not match I2C slave Equipment requirements will also produce Nack The signal .

3、 When peripherals require reading timing, the middle is stop The signal is not repeat start When it's a signal , How to deal with ？

At this time, you need to call twice i2c_transfer, I2C read Split into two , Revised 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;
}

Believe the above I2C debug Methods have been able to solve most problems for everyone , If it doesn't work out , Generally, it is the bottom layer of the original chip factory code bug, You can find the original chip manufacturer to support .