I2C clock stretching or associated issue with SCD30 sensor

[SloMusti]

I have been testing the SCD30 sensor(https://www.sensirion.com/en/environmental-sensors/carbon-dioxide-sensors-co2/) with https://github.com/sparkfun/SparkFun_SCD30_Arduino_Library library and the sensor does not work with this core. What occurs is that the measurement start commands do not get recognized and the sensor does not start measuring.

Minor modifications for this library to work with the core: https://github.com/sparkfun/SparkFun_SCD30_Arduino_Library/blob/master/src/SparkFun_SCD30_Arduino_Library.cpp#L43 adding _i2cPort->setClockLowTimeout(250); to enable clock stretching correctly

Same library works well on ESP32 and other boards used for testing.

Issue breakdown: Communication seems to work with the decoder as all writes get acknowledged and the protocol decoder will give the identical printout, however we can see two key differences in the logical levels of SDA and SCL.

• After clock stretching SCL is released by slave, SDA line does not go high for a short pulse
• After writing multiple bytes (sending two command bytes and values and CRC), clock stretching of 15-150ms is expected and can be seen in the working example, however not using this core.

Possible causes of this issue:

• SCL clock pulse shape is slightly different, with the 100kHz speed the low pulses are rather shorter then high pulses, but that may be minimal
• SDA line does not get released correctly and a false ack is read

working_scd30_esp32_clock-stretch working_scd30_esp32_sda_released_stratching not-working_scd30_stm32l0_no_stretch_at_end not-working_stm32l0_no_sda_release

@GrumpyOldPizza any thoughts?

[GrumpyOldPizza]

Interesting. The Wire.setClockLowTimeout(250) command actually just enables the timeout to abort a transfer if the slave stretched SCL for too long. Per default (and I2C spec) this timeout is disabled.

Which of the images is "good" and which one is "bad" ?

[SloMusti]

@GrumpyOldPizza updated the post with description of images, my bad as they were only specified in filenames. Should be clear now.

Abort does not seem to happen here, more like that the clock stretching is ignored.