I2C errors and importance of BUSY flag

I2C Error Types

Bus error: 

This error happens when the interface detects an SDA’s rising or falling edge while SCL is high, occurring in a non-valid position during a byte transfer.

During the byte transfer, if any invalid transition happens on the SDA line, then the bus error is triggered, and the bus error flag in the status register will be set, and if the interrupt is enabled, then an interrupt will be triggered on the interrupt IRQ line.

Arbitration loss error: 

This error can occur when the interface loses the arbitration of the bus to another master. Basically, arbitration loss error may happen only in the multi-master bus configuration. The circuit having multiple masters is known as multi-master configuration.

ACK failure error:

This error occurs when no ACK is returned for the byte sent.

Overrun error:

• Occurs during reception when a new byte arrives before reading the previous data.
• Mitigated by clock stretching or handling the BTF flag.

Remember that the overrun always happens during the reception. When a new byte is received before reading the previously received values in the data register, the newly received data will be lost. In such cases, the overrun error occurs. 

For example, consider that there is one data register (DR) and a shift register (SR) in I2C. The software reads the data from the data register. When SR receives one byte, it is moved to the DR. Now assume that DR is full, one byte that is not yet read by the software is already there in the DR, and the second byte is received in the SR. Now the SR has the second byte, and DR has the first data byte. When the third byte comes, the I2C peripheral discards the third byte since there is no place to keep the third byte received. This condition is called overrun. 

The overrun error will not occur in I2C if clock stretching is enabled because this error happens only when both the DR and SR register is filled. Another flag called BTF is set immediately, indicating that both SR and DR registers are full, and the clock will be stretched automatically. When the clock is stretched, both slave and master enter into the waiting state. The BTF flag will get cleared only when the software reads a byte from the data register.

If the clock stretching feature is not supported by the I2C peripheral, then overrun error may happen, and the software has to be careful with that.

Note: In I2C, the overrun and underrun will not happen if clock stretching is enabled because in those conditions, the clock will be held LOW, and both communicating devices will enter the wait state.

Underrun: 

It happens in transmission when a new byte should be sent, and the data register has not been written yet, and the same byte is sent twice.

PEC error: 

The PEC error happens when there is a CRC mismatch if you have enabled the CRC feature.

Time-Out error:

The time-out error occurs when the master or slave stretches the clock by holding it low for more than the recommended amount of time. The recommended amount of time will be mentioned in the reference manual. If the stretching of the clock to low exceeds the recommended amount of time, then the time-out error will be triggered by the I2C peripheral.

These are some of the I2C errors that may occur in the I2C peripheral. We have to catch those errors, and the driver should report that error to the application. Then the application may take appropriate action.

For example, if it is ACK failure, then the application may try another address. If it is an arbitration loss, then the application may try after some time, and if it is a bus error, then the application may restart the communication, etc. The driver’s job is to catch the error and notify the application.

BTF flag in TX and preventing underrun:

Let’s understand what is a BTF flag in TX and how it can be used to prevent the underrun error. Remember that the BTF flag is applicable both in TX as well as RX.

Significance of BTF flag during TX:

During Txing of a data byte, if TXE=1, then that means the data register is empty. And if the firmware has not written any byte to the data register before the shift register becomes empty (previous byte transmission), then the BTF flag will be set, and the clock will be stretched to prevent the underrun. 

Consider that in TX, you have a data register and shift register.

Now let’s say software writes one byte of data into the DR. Then the data byte in the DR will be copied into the SR or shift register. After receiving the data, the SR will start transmitting that byte to the external world. The TXE becomes one since the DR is empty.

When TXE becomes 1, the software should put another byte into the DR. Otherwise, the DR will load an invalid byte to SR when SR becomes empty, and then the SR will transmit the same invalid data to the external world, which is actually wrong. This problem can be avoided by using the BTF flag.

When you use the clock stretching option, if the software didn’t write the second byte to the DR, then once the shift register completes sending the current byte, the BTF will be set to 1, and the clock will be stretched.

When both TXE and BTF become 1, that means that both the DR and SR are empty, and the clock will be stretched to avoid the underrun error. If you don’t use the clock stretching, then the BTF will not be set, and there is a chance of underrun.

BTF flag in RX and preventing overrun:

BTF Flag in RX:

Let’s understand the significance of the BTF flag in RX and how it can prevent the overrun error.

IF RXNE=1, then it means new data is waiting in the data register, and if the firmware has not read the data byte yet before the shift register is filled with another new data, then also the BTF flag will be set, and the clock will be stretched to prevent the overrun.

In the following article, let’s modify the I2c handle structure . 

FastBit Embedded Brain Academy Courses,

Click here: https://fastbitlab.com/course1