You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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" ?
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 correctlySame 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.
Possible causes of this issue:
working_scd30_esp32_clock-stretch
![working_scd30_esp32_clock-stretch](https://user-images.githubusercontent.com/1584734/61969234-5082ee00-afda-11e9-92aa-cf03d7e77a80.png)
![working_scd30_esp32_sda_released_stratching](https://user-images.githubusercontent.com/1584734/61969236-5082ee00-afda-11e9-803b-659b8384834f.png)
![not-working_scd30_stm32l0_no_stretch_at_end](https://user-images.githubusercontent.com/1584734/61969243-52e54800-afda-11e9-89c2-ae1c98ccc382.png)
![not-working_stm32l0_no_sda_release](https://user-images.githubusercontent.com/1584734/61969244-537dde80-afda-11e9-9625-61198aa017ae.png)
working_scd30_esp32_sda_released_stratching
not-working_scd30_stm32l0_no_stretch_at_end
not-working_stm32l0_no_sda_release
@GrumpyOldPizza any thoughts?
The text was updated successfully, but these errors were encountered: