I am trying to read temperature from a SHT21 sensor using an ESP32-WROOM board. The I2C driver is from ESP-IDF SDK. This is my reading sequence:
cmd = i2c_cmd_link_create();
i2c_master_start(cmd); // Send i2c start on bus
i2c_master_write_byte(cmd, (I2C_ADD<<1) | I2C_MASTER_WRITE, 1);
i2c_master_write_byte(cmd, command, 1);
i2c_master_start(cmd);
i2c_master_write_byte(cmd, (I2C_ADD<<1) | I2C_MASTER_READ, 1);
i2c_master_read_byte(cmd, data+0, 1); // data MSB
i2c_master_read_byte(cmd, data+1, 1); // data LSB
i2c_master_read_byte(cmd, &checksum, 1); // CRC
i2c_master_stop(cmd);
ret = i2c_master_cmd_begin(I2C_NUM_0, cmd, 1000 / portTICK_RATE_MS);
i2c_cmd_link_delete(cmd);
Based on the recording from my logical analyser I can tell that all write commands are executed properly. However there is no clock for reading the response from sensor. The CLK line remains low for another 41 ms.
So where is the clock for reading the response? Am I using the I2C driver incorrectly? Is the 41 ms delay produced by the sensor because of clock stretching? But shouldn't then the ESP32 continue with the reading clock afterwards? Am I missing anything else?
Thanks for all responses!
Best Answer
RTFM (or the SHT21 datasheet in this case). The
E3
command is "hold master" mode - the datasheet explicitly says:So eveything normal in your logic analyer shot above.
Depends on how I²C is implemented - and whether clock stretching is actually supported. Some TWI implementations may not support slave clock stretching.
Note that the 41ms dead time could also trigger the watchdog.
I recommend trying no-hold master mode with properly timed read access, that is 85ms for 14-bit
T
and 29ms for 12-bitRH
according to the datasheet.