Does the Raspberry Pi 4 (and previous models) support the I²C clock stretching feature?

Some I²C devices, e.g., Bosche BNO055, Sensirion SCD-30, require this feature and the communication is likely to be unreliable or will fail without it.

From the I²C specification this is described in section 3.1.9 as:

Clock stretching pauses a transaction by holding the SCL line LOW. The transaction cannot continue until the line is released HIGH again. Clock stretching is optional and in fact, most slave devices do not include an SCL driver so they are unable to stretch the clock.

On the byte level, a device may be able to receive bytes of data at a fast rate, but needs more time to store a received byte or prepare another byte to be transmitted. Slaves can then hold the SCL line LOW after reception and acknowledgment of a byte to force the master into a wait state until the slave is ready for the next byte transfer in a type of handshake procedure (see Figure 7).

On the bit level, a device such as a microcontroller with or without limited hardware for the I2C-bus, can slow down the bus clock by extending each clock LOW period. The speed of any master is adapted to the internal operating rate of this device.

In Hs-mode, this handshake feature can only be used on byte level (see Section 5.3.2).

This question is not about the RP2040-based Pi Pico.

Reducing the I²C master's clock speed below standard mode's 100 kHz is not clock stretching in the context of this question and the I²C specification.

I see some discussion about this over on Raspberry Pi Forums: I2C clock stretching support in Raspberry Pi 4 (BCM2711)?.


The Pi 4 appears to support clock stretching on the software I2C bus:


The hardware I2C bus is affected by the same bug as earlier models which makes it incompatible with clock stretching, as the screenshot in your referenced post shows:

enter image description here

  • 2
    In other words, (1) Rpi4B hardware I2C does not support bus stretching, though software I2C does. (2) Rpi4B can workaround by lowering I2C speed to 50kHz. (3) Rpi3B+ I2C speed is fixed at 100kHz, and cannot change, because of a bug. In other words, Rpoi3B+ has bad luck.
    – tlfong01
    Jun 7 at 0:57
  • 1
    @tlfong01: hmmm... says who? I can perfectly set my RPi3B+ both to exact 100kHz as well as exact 400kHz for the I2c clock speed. You only have to set a few lines in the config.txt file to get that speed: core_freq=250 and dtparam=i2c_baudrate=100000 for 100kHz, dtparam=i2c_baudrate=400000 for 400kHz. And everything in between...
    – GeertVc
    Jun 10 at 17:38
  • (1) Yes, you can set RPi3B+ I2C speed to 100kHz and 400kHz without any error messages. But if you use a scope to display the waveform, you see nothing changes.
    – tlfong01
    Jun 11 at 1:36
  • @tflong01 Perhaps you two are referring to the effect clock stretching has on the actual bus speed vs the set/request bus speed on the master? I didn't realise until recently that this feature always slows down the bus to some extent. See GitHub: raspberrypi/pico-sdk: i2c speed incorrect and non-linear giving significant error for 400kHz #283 for an example of this on the Pi Pico. BTW, I have never seen this called bus stretching. Jul 24 at 20:26
  • @dmitry-grigoryev Thanks. Any chance you could add the Raspberry Pi pin names and numbers for bus=3 and a reminder that only GPIO2 (pin 3) and GPIO3 (pin 5) have the 1.8k pull-up resistors? That'll help people not intimately familiar with this range of boards. Jul 24 at 20:27

Models earlier than the Pi4 (those based on the BCM2835 SOC) are known to have a buggy implementation of clock stretching.


I do not know if this bug has been fixed in the BCM2711 SOC used by the Pi4B and the Pi400.

  • Can you summarise the nature of the bug here? Jun 7 at 7:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.