What is clock stretching, and why must every I2C master support it?

Clock stretching is a flow-control mechanism where a slave holds the SCL line low after the master releases it, effectively pausing the transaction. The master generates each clock pulse by pulling SCL low, then releasing it. Normally, the pull-up resistor brings SCL back high immediately. But if the slave is still holding SCL low (via its open-drain output), the line stays low — and the master must wait.

A slave stretches the clock when it needs time to process data before the next byte. Typical scenarios: (1) an EEPROM that needs 5 ms to complete an internal page write before it can accept the next command, (2) a software-implemented I2C slave on a slow MCU that cannot keep up with a fast master, (3) an I2C slave that must perform a computation (e.g., CRC calculation) before providing the response byte.

The I2C specification requires every master to support clock stretching — the master must check that SCL has actually gone high after releasing it, rather than assuming it will. A master that ignores clock stretching will proceed with the next bit while SCL is still low, causing complete desynchronization of the transaction. In HAL-based drivers this is handled automatically, but in bit-banged implementations, failing to read SCL back after releasing it is a common and subtle bug.

The danger of clock stretching is that there is no timeout defined in the base I2C specification. A malfunctioning slave can hold SCL low indefinitely, locking up the entire bus. This is one reason SMBus (which adds a 35 ms timeout) was created. In practice, firmware should implement a timeout on the master side — if SCL does not go high within a reasonable period (e.g., 25 ms), declare a bus error and initiate bus recovery.