Discussion on the Stability of I2C communication

I recently encountered some problems when debugging I2C. I hope you can help me with similar problems.

Keywords: I2C sub-steady state low speed signal dejitter

 

[Prelude]
In the system, the I2C slave function must be implemented in the CPLD to communicate with the I2C interface of the CPU, so as to expand the gpio port of the system. Therefore, according to the requirements of I2C protocol, an I2C slave module and testslave module are compiled with OpenGL, and then simulated and verified in Modelsim simulation to meet the design requirements. Then, the compiled. Jed file is burned into the CPLD chip for computer testing and verification.

The system uboot has an I2C master function. Therefore, you can perform read or write operations on the I2C bus through the serial port, and perform multiple tests on multiple duts to verify that the read or write results are correct. At the same time, the I2C bus signal is captured and read by the oscilloscope, which is consistent with the result. The CPLD code is OK.
(Note: the I2C interface is a simple and low-speed serial interface, which includes two lines: clock signal (SCL) and data signal (SDA). the I2C bus is used for communication between the host and slave, that is, master and slave .)

 

[Symptom]
Stability Test: A New i2ctest module is added to uboot, which keeps writing and reading I2C slave (CPLD, determine whether the communication is successful by checking whether the written data is consistent with the read data. The test data increases from 0 to 255 (the I2C communication data width in the system is 8 bit ), after a test is completed, the data starts from 0 again until the communication fails. Modify and update the code in the CPLD to meet the requirements of i2ctest.

Then, the I2C stability test was conducted on dut, and it was found that there were hundreds to thousands of cycles (256 write and read operations each cycle), and there would be an error in I2C communication. After multiple tests, it is found that the error type is different when an error occurs, which may be:
1. The read and write results are inconsistent. In this case, the read results are correct when you manually press the command.
2. After the master sends the address + read/write command, it does not receive the ACK from slave.
3. After the master writes data, it does not receive the ACK from slave.
4. The master loses the arbitration right. After this error occurs, the I2C bus remains in use and the Master cannot be controlled.

 

[Problem analysis and solution]
According to the above test results, the I2C communication error is not fixed and the probability is different. Therefore, the following test and verification are performed:
1. Source Code Analysis and re-check: first, re-check the I2C slave module code, draw a detailed state chart of the state machine, and check according to I2C communication commands. the jump of the state machine is correct. Secondly, the ID function generated at the beginning/end of I2C communication is implemented using another method (multiple sampling and sampling methods). Then, the I2C communication error still occurs during testing, the description and generate the start/end sign functions are not closely related. (Out-of-question note: in fact, the slave code is not very problematic early in the morning, because for logical devices, the status jump is triggered by level. If it is a design error, communication fails. To fully verify the code accuracy, check all the code again)

 

2. Add a lamp in the CPLD code to determine the status of the CPLD jump when an error occurs. At the same time, use the oscilloscope to assist in capturing the SCL/SDA Waveform when an error occurs.
Multiple tests showed that the CPLD state machine jump did not jump as specified when an error occurred! For example, no ACK is generated after receiving the address + read/write command from the master. The status indicator indicates that the state machine is still in the strt_search state (connected to the received address + read/write command for comparison, to determine whether the Server Load balancer address selected by the master is itself and to determine whether to read or write commands), it indicates that the communication address detected by the CPLD is not the Server Load balancer address of the CPLD, the address captured on the oscilloscope is indeed the slave address! This indicates that when an error occurs, the CPLD fails to correctly capture the data sent from the master. It may be because the signal is disturbed during communication, and the data is not correctly received.

 

3. Comparison test: The same uboot and CPLD programs are burned to the 24fe_dev1 (the previous version of the 24fe_dev2 prototype) and 24ge_dev1 (the same series of GE solutions) Boards for testing, no error occurred after multiple long-term tests! This shows that there is no problem with the CPLD code, and the problem should be on the 24fe_dev2 board.

 

4. Detailed signal test: The GHz bandwidth oscilloscope is used to test the signal quality of the three boards, and no major difference is found between the three, the up-pull resistance of the SCL/SDA signal is 4.7 kb, and the rising edge of the SCL/SDA signal is around NS, while the falling along time is 3 ~ 5ns, but we found that there was an interference signal on the rising edge of the 24 fe_dev2 model! Is it because of this interference signal that the CPLD misjudges the signal? (Note: the I2C communication rate is 100 kHz. Because it is a low-speed signal, the hardware debugging is not concerned. Only some basic signal tests are carried out to verify that the data establishment/retention time meets the requirements. In fact, I have already made a subjective mistake. This lesson tells me that no low-speed signal can be treated in a careless manner, and edge transformation of low-speed signals (especially edge-triggered signals) must be measured with a high-bandwidth oscilloscope)

 

5. Adjust the upper-tension resistance of the SCL/SDA to 1.5 kb, and perform other tests (Millions of read and write operations) without any exception.

 

The reasons for the unstable I2C communication are as follows:
Because the Rising Speed of the SCL/SDA signal is around 220ns (1000ns Max in standard mode in I2C Protocol), the time in the sub-steady state is longer (0.3vdd ~ 0.7vdd). If the signal is disturbed during this period, its level is not in the valid logical level range and is changing, this leads to different judgments made by the digital component CPLD connected to it, some as '1', some as '0', and some into the sub-steady state, and the CPLD may be logically disordered, as a result, the I2C slave state machine jumps and an I2C communication error occurs. The I2C slave code is analyzed without any preventive measures. Therefore, I2C communication errors may occur when the Board has a large amount of interference.
For the 24ge_dev1 and 24fe_dev1 prototypes, no I2C communication exception is found. Only the 24fe_dev2 board is displayed, indicating that the 24fe_dev2 board has a greater interference than the other two. On the 24fe_dev2 board, adjust the display resistance to 1kb ~ At K, the rising time of the SCL is shortened to 60 ~ 80ns, the time in the sub-steady state is greatly reduced, so the probability of interference is also greatly reduced, so the chance of I2C communication errors is greatly reduced, there is no exception at present. However, in theory, the signal may still be subject to external interference in the sub-steady state, but the time of the signal in the sub-steady state becomes very short and the probability of interference is very low.

 

Solution and verification:
1. Adjust the upper drawing resistance of the SCL/SDA to 1.2 ~ 1.5 K (the smaller the resistance, the shorter the rise time, the lower the chance of interference, but according to the I2C Protocol requirements, the upper-pull resistance cannot be too small, must be greater than (VDD-volmax) /3mA = (3.3 V-0.4 V)/3mA = 0.97 K), which can effectively solve the problem of I2C stability, but has risks. On the prototype, the pull-up resistance is adjusted to K for stability testing. The stability test passes 72-hour testing at normal temperature.

2. debounce the SCL/SDA signal: Filter and deshake the SCL/SDA signal (see the following section), so that the CPLD can accurately determine the change of the SCL/SDA signal, the quick clock can be used to perform multiple sampling for the SCL/SDA signal to accurately determine the high and low levels of the SCL/SDA, thus avoiding the sub-steady state phase of the signal, which can fundamentally solve the problem of I2C instability. After this function is added to the existing I2C slave code, it is tested on multiple prototypes. The 72-hour test at normal temperature does not show an error, and then it is placed in the aging box for high (60 °) low (-10 °), regular (25 °) temperature stability tests, each 24 h stability test, were successful pass. This method can effectively solve the I2C stability problem!
'Define deb_i2c_len 4 // note: the source code is set based on the system. The source code is from the open source website.
// 3.1) opencores 'i2c slave, debounce SDA and SCL
Always @ (posedge fast_clk or negedge resetn)
Begin
If (! Resetn)
Begin
Sdapipe <= {'deb _ i2c_len {1 'b1 }};
Sdadeb <= 1 'b1;
Sclpipe <= {'deb _ i2c_len {1 'b1 }};
Scldeb <= 1 'b1;
End
Else
Begin
Sdapipe <= {sdapipe ['deb _ I2C_LEN-2: 0], SDA };
Sclpipe <= {sclpipe ['deb _ I2C_LEN-2: 0], SCL };
If (& sclpipe ['deb _ I2C_LEN-1: 1] = 1 'b1)
Scldeb <= 1 'b1;
Else if (| sclpipe ['deb _ I2C_LEN-1: 1] = 1' B0)
Scldeb <= 1' B0;
If (& sdapipe ['deb _ I2C_LEN-1: 1] = 1 'b1)
Sdadeb <= 1 'b1;
Else if (| sdapipe ['deb _ I2C_LEN-1: 1] = 1' B0)
Sdadeb <= 1' B0;
End
End

Of course, this problem can be effectively solved if a device such as the Schmidt trigger is used to determine the delay. Because the CPLD pin on the Board does not have this function (some more advanced CPLD has this function), it cannot be verified.

 

[Summary]
It can be said that this is a "blood case" caused by low-speed signals and a vivid example of the "sub-steady state" problem! Even in the face of low-speed signals, our hardware engineers cannot take it lightly, and their slow rising or falling edges (meeting their standard requirements) lead to a long time in the sub-steady state, the longer you wait in this period of time, the more dangerous it will be. The more likely it will be to be disturbed! If we want to use it as a trigger signal, it is even more dangerous. If we have to do so, remember to debounce it. After the debounce process, the signal will have a latency of several hundred NS (you can adjust the code to set according to the requirements of the system), but for ample time to establish/maintain, does not affect system communication. (In this system, Tsu and thd have a large margin. Therefore, when using a similar method to process low-speed signals, pay attention to whether the time series parameters of signals after debounce still meet the requirements! Otherwise, a new problem will be introduced !)