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)?.

3 Answers 3


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

  • 3
    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, 2021 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, 2021 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, 2021 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, 2021 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, 2021 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, 2021 at 7:40

For my hardware (RPi3b, RPi4 compute), the nasty clock stretch bug disappears immediately when setting BSC[n]->TOUT to zero. For RPi4 and I²C1 (Pins 3 and 5) this can be done with preinstalled tool called “busybox”:

sudo busybox devmem 0xFE80401C 32 0

There is no reason why an I²C master implements any revert from too-long-clock-stretch. In case of a slow-responsive or non-responsive slave, the I²C bus is blocked. Period. The only chance to release the bus is: Reset or disconnect the faulty I²C slave.

  • While this information seems to be true (correct way to address that TOUT register) it doesn't seem to change the issue with a BNO055 sensor. With this type of sensor software i2c seems to be the only working option so far. Also take a look at this thread: github.com/raspberrypi/linux/issues/4884
    – wschopohl
    Nov 21, 2023 at 12:39
  • Sorry I forgot to note that the I²C slave was an ATmega328 with I²C in slave mode. Microcontrollers with I²C in hardware typically require clock-stretch before ACK/NAK signaling. And, a Raspberry supports (i.e. waits on) clock stretch only in this situation. No Raspberry supports clock-stretch on every clock edge (i.e. in the middle of a byte). As the datasheet of BNO055 is very incomplete describing its clock-stretch, I guess that chip uses bitwise clock-stretch, and, if so, it will never run with Raspberry I²C hardware master. Nov 23, 2023 at 9:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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