Important solution to hardware I2C deadlock of stm32f129

First of all, I would like to thank the enthusiastic netizens for their selfless dedication. Let me describe my problem first. The chip I use is STM32F429IGTx. When communicating with MPU9250/6050, I tested the software reset several times and it was locked. After the hardware power reset, everything was normal. There was no I2C lock problem when communicating with the camera.

For hardware IIC, please refer to my previous post http://bbs.21ic.com/icview-1034518-1-1.html , which is also detailed enough. Here is another problem I found.

There is no problem with the hardware iic. It is some problem with the iic slave device. EEPROM does not have similar problems. MPU6050 has this kind of problem of pulling down SDA and locking it. My previous solution was to power off and reset the mpu to solve it, but now I have found a new solution.
I will repost a blog to describe the phenomenon. Reposted from "Zhang Peng's Blog"
I2C is a serial data communication protocol invented by Philips, which only uses two signal lines: SerialClock (SCL for short) and SerialData (SDA for short). I2C is a bus structure, 1 Master, 1 or more Slaves, and each Slave device is distinguished by a 7-bit address, followed by a read-write bit, indicating read (=1) or write (=0), so we can sometimes see 8-bit device addresses. At this time, each device has two addresses for read and write, and the high 7-bit addresses are actually the same.

The I2C data format is as follows:
No data: SCL=1, SDA=1;
Start bit (Start): When SCL=1, SDA jumps from 1 to 0;
Stop bit (Stop): When SCL=1, SDA jumps from 0 to 1;
Data bit: When SCL jumps from 0 to 1, the sender controls SDA, and SDA is valid data at this time, and SDA cannot be changed at will;
When SCL remains at 0, the data on SDA can be changed at will;
Address bit: The definition is the same as the data bit, but it is only sent from Master to Slave;
Acknowledge bit (ACK): When the sender has transmitted 8 bits, the sender releases SDA, and the receiver controls SDA, and SDA=0;
No acknowledge bit (NACK): When the sender has transmitted 8 bits, the sender releases SDA, and the receiver controls SDA, and SDA=1.

When the data is transmitted in single byte, the format is:
Start bit, 8-bit address bit (including 1 read/write bit), acknowledgement, 8-bit data, acknowledgement, stop bit.
When the data is transmitted as a string of bytes, the format is:
start bit, 8-bit address bit (including 1 read/write bit), acknowledgement, 8-bit data, acknowledgement, 8-bit data, acknowledgement, ..., 8-bit data, acknowledgement, stop bit.

It should be noted that:
1. SCL is always controlled by the Master. SDA is controlled by the Slave when reading data and by the Master when writing data according to the direction of data transmission. After the 8-bit data is transmitted, the SDA control right of the acknowledgement bit or the non-acknowledgement bit is opposite to that of the data bit transmission.
2. The start bit "Start" and the stop bit "Stop" can only be sent by the Master.
3. After the 8 bits of the address are transmitted, the Slave device that has successfully configured the address must send "ACK". Otherwise, after a certain period of time, the Master will be regarded as timed out, and will give up the data transmission and send "Stop".
4. When writing data, after the Master sends 8 data bits, the Slave device should reply "ACK" if there is still room to receive the next byte. If the Slave device does not have room to receive more bytes, it should reply "NACK". When the Master receives "NACK" or does not receive any data after a certain period of time, it will be regarded as a timeout. At this time, the Master abandons data transmission and sends "Stop".
5. When reading data, after the Slave device sends 8 data bits, if the Master wants to continue to read the next byte, the Master should reply "ACK" to prompt the Slave to prepare the next data. If the Master does not want to read more bytes, the Master should reply "NACK" to prompt the Slave device to prepare to receive the Stop signal.
6. When the Master speed is too fast and the Slave end cannot process it in time, the Slave device can pull down SCL and hold it (SCL=0 will cause "wired AND") to prevent the Master from sending more data. At this time, the Master will slow down or end the data transmission depending on the situation.

In actual applications, there is no mandatory requirement that the data receiver must respond to the 8-bit data sent, especially when both the Master and Slave ends are implemented using GPIO software simulation methods. The programmer can agree on the length of data transmission in advance, and the slave does not check NACK, which can sometimes reduce system overhead. However, if the slave side is hardware i2c and requires a standard NACK, and the master side is GPIO software simulating i2c and does not send NACK correctly, "slave cannot receive stop" will appear, causing i2c to hang.

Under normal circumstances, the I2C bus protocol can ensure normal read and write operations of the bus. However, when the I2C master device is abnormally reset (watchdog action, abnormal power supply on the board causes reset chip action, manual button reset, etc.), it may cause I2C bus deadlock. The following is a detailed explanation of the causes of bus deadlock.

    During the read and write operation of the I2C master device, the master device controls SCL to generate 8 clock pulses after the start signal, and then pulls down the SCL signal to a low level. At this time, the slave device outputs a response signal and pulls the SDA signal to a low level. If the master device is abnormally reset at this time, SCL will be released to a high level. At this time, if the slave device is not reset, it will continue the I2C response and pull SDA to a low level until SCL becomes a low level, and then the response signal will end. For the I2C master device, after the reset, the SCL and SDA signals are detected. If the SDA signal is found to be a low level, it will be considered that the I2C bus is occupied, and it will wait for the SCL and SDA signals to become a high level. In this way, the I2C master device waits for the slave device to release the SDA signal, and at the same time, the I2C slave device is waiting for the master device to pull down the SCL signal to release the response signal. The two wait for each other, and the I2C bus enters a deadlock state. Similarly, when I2C performs a read operation, the I2C slave device responds and outputs data. If the I2C master device is abnormally reset at this moment and the data bit output by the I2C slave device is exactly 0, the I2C bus will also enter a deadlock state.

method

    (1) Try to choose an I2C slave device with a reset input.

    (2) Connect the power supplies of all slave I2C devices together and connect them to the main power supply through MOS tubes, and the on and off of the MOS tubes are realized by the I2C master device.
    (3) Design the watchdog function in the I2C slave device.

    (4) Add an I2C bus recovery procedure in the I2C master device.

        Each time the I2C master device is reset, if it detects that the SDA data line is pulled low, the SCL clock line in the I2C is controlled to generate 9 clock pulses (for the case of 8-bit data, the method of "9 clks can be activated" comes from NXP's documentation. As the originator of the I2C bus, NXP (Philips) is credible), so that the I2C slave device can complete the suspended read operation and recover from the deadlock state.

        This method has great limitations, because the I2C modules of most master devices are implemented by built-in hardware circuits, and the software cannot directly control the SCL signal to simulate the required clock pulses.

        Alternatively, sending an I2C_Stop condition can also cause the slave device to release the bus.

        If the GPIO is used to simulate the I2C bus, add the I2C bus status detection I2C_Probe before the I2C operation. If the bus is occupied, try to restore the bus and then operate after the bus is released. To ensure the integrity of the smallest unit of I2C operation, it should not be interrupted by other events (interrupts, high-priority threads, etc.).

  (5) Add an additional bus recovery device to the I2C bus. This device monitors the I2C bus. When the device detects that the SDA signal is pulled low for more than a specified time, it generates 9 clock pulses on the SCL bus, allowing the I2C slave device to complete the read operation and recover from the deadlock state. The bus recovery device needs to have a programming function, which can generally be implemented using a microcontroller or CPLD.

  (6) Connect an I2C buffer with deadlock recovery to the I2C bus. For example, Linear's LTC4307 is a bidirectional I2C bus buffer with I2C bus deadlock recovery function. The LTC4307 bus input side is connected to the master device, and the bus output side is connected to all slave devices. When the LTC4307 detects that the SDA or SCL signal on the output side is pulled low for 30ms, it automatically disconnects the input and output sides of the I2C bus. And 16 clock pulses are generated on the output side SCL signal to release the bus. When the bus is successfully recovered, the LTC4307 will reconnect the input and output sides to enable the bus to work normally.

    Well, the phenomenon has been described very clearly here. Many people say that the hardware iic is internally controlled and cannot perform operations to control the scl pin to output pulses. In fact, it can be done. When configuring iic, first configure the scl hardware to open drain instead of multiplexed open drain. In this way, you can take the initiative of the scl pin and control it to output 9 clock pulses. Then configure it to multiplexed open drain, and then configure iic. This is to solve the potential problems of the slave device first, and then use it. The idea has been explained very clearly. Here is a sample code.

[cpp]  view plain  copy

1. RCC_APB1PeriphClockCmd(SENSORS_I2C_RCC_CLK, ENABLE);  

2. RCC_APB1PeriphClockCmd(SENSORS_I2C_SCL_GPIO_CLK, ENABLE);  

3.       

4. /** Add a section of bus release operation, 9 SCL clock pulses, to prevent the slave device from pulling down the occupied bus and not releasing it in some extreme cases, causing deadlock **/  

5. GPIO_InitStructure.GPIO_Pin = SENSORS_I2C_SCL_GPIO_PIN;   

6.   GPIO_InitStructure.GPIO_Speed ​​= GPIO_Speed_100MHz;  

7.   GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;  

8.   GPIO_Init(SENSORS_I2C_SCL_GPIO_PORT, &GPIO_InitStructure);    

9.   for(i = 0; i < 10; i++) //Generate 9 SCL clock pulses  

10.   {  

11.     GPIO_SetBits(SENSORS_I2C_SCL_GPIO_PORT, SENSORS_I2C_SCL_GPIO_PIN);  

12.     Delay_us(100);  

13.     GPIO_ResetBits(SENSORS_I2C_SCL_GPIO_PORT, SENSORS_I2C_SCL_GPIO_PIN);  

14.     Delay_us(100);  

15.   }    

16.    /* Enable I2Cx clock */  

17.   RCC_APB1PeriphClockCmd(SENSORS_I2C_RCC_CLK, ENABLE);  

18.   

19.   /* Enable I2C GPIO clock */  

20.   RCC_AHB1PeriphClockCmd(SENSORS_I2C_SCL_GPIO_CLK | SENSORS_I2C_SDA_GPIO_CLK, ENABLE);