Definition about Clock Stretching:
In an I2C communication, the master device determines the clock speed. Unlike RS232 the I2C bus provides an explicit clock signal which relieves master and slave from synchronizing exactly to a predefined baud rate.
However, there are situations where an I2C slave is not able to co-operate with the clock speed given by the master and needs to slow down a little. This is done by a mechanism referred to as clock stretching.
An I2C slave is allowed to hold down the clock if it needs to reduce the bus speed. The master, on the other hand, is required to read back the clock signal after releasing it to the high state and wait until the line has actually gone high.
Issue Summary:
The ARM-processor Broadcomm BCM2835, which is used on the Raspberry Pi3, has a serious bug in its I2C implementation, which can (a) prevent I2C communication with some devices and (b) lead to data corruption (both in read and write direction).
As a result, do not use I2C-devices which use clock-stretching directly with the Raspberry Pi3 directly or any other Broadcomm BCM2835-based device.
Explanation:
Sample Program:
Clock Diagram:
In the above figures, SCL Pulse shows the read-error issue(Red = Error, Green = OK)
!--------------------------------------------------------------------------------------------------------------------------------!
In an I2C communication, the master device determines the clock speed. Unlike RS232 the I2C bus provides an explicit clock signal which relieves master and slave from synchronizing exactly to a predefined baud rate.
However, there are situations where an I2C slave is not able to co-operate with the clock speed given by the master and needs to slow down a little. This is done by a mechanism referred to as clock stretching.
An I2C slave is allowed to hold down the clock if it needs to reduce the bus speed. The master, on the other hand, is required to read back the clock signal after releasing it to the high state and wait until the line has actually gone high.
Issue Summary:
The ARM-processor Broadcomm BCM2835, which is used on the Raspberry Pi3, has a serious bug in its I2C implementation, which can (a) prevent I2C communication with some devices and (b) lead to data corruption (both in read and write direction).
As a result, do not use I2C-devices which use clock-stretching directly with the Raspberry Pi3 directly or any other Broadcomm BCM2835-based device.
Explanation:
Sample Program:
Clock Diagram:
I2C Read:
Configuration:
- I2C read
- I2C slave address: 0x4F
- read 2 bytes: 0x00 0x00
- varying ACK/NACK-delays
- Results:
I2C clock-stretching only work at the end of I2C-read-ACK-phases (after reading ACK/NACK), not at the beginning.
I2C clock-stretching at the end/directly after an I2C-read-ACK-phase only works correctly, if the slave stretches SCL by more than 0.5 I2C clock periods. (see delays/picture-numbers >= 11 below)
Delays which are shorter than 0.5 I2C clock periods corrupt the data, even when the delay is very short and even when the slave catches the too-short clock pulse. (see delays/picture-numbers 1..10 below)
In the above figures, SCL Pulse shows the read-error issue(Red = Error, Green = OK)
!--------------------------------------------------------------------------------------------------------------------------------!
