Closed berkutta closed 7 years ago
Thanks for the very clear description. I think it might be related to "no external Pullups", I will try to look into this.
I tried to reproduce this issue with strong Pullups on SDA and SCL (1kOhm). Exactly the same behaviour. I've even tried to use a Ferrite bead between ESP32 and Sensor on both lines. This helped in some situatons on the ESP8266. But no luck on the ESP32..
Add set level code in i2c_set_pin can fix the issue. Trying to merge to idf ASAP.
esp_err_t i2c_set_pin(i2c_port_t i2c_num, gpio_num_t sda_io_num, gpio_num_t scl_io_num, gpio_pullup_t sda_pullup_en, gpio_pullup_t scl_pullup_en, i2c_mode_t mode)
{
.......
if (sda_io_num >= 0) {
gpio_set_level(sda_io_num, 1);
PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[sda_io_num], PIN_FUNC_GPIO);
......
}
if (scl_io_num >= 0) {
gpio_set_level(scl_io_num, 1);
PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[scl_io_num], PIN_FUNC_GPIO);
.......
}
......
}
I'm using a own function names "i2c_master_init()" to initialize the i2c subsystem on the ESP32. After calling this function I get pulses/spikes on SDA/SCL which some Slaves interprets as an "START". This behaviour results in errors on later real "START"'s which prevents to directly use those Slaves. A workaround is to make a dummy request to those Slaves ("START", WRITE ADDRESS", "STOP")
My hardware consists of no external Pullups. I've used the Sparkfun ESP32 Thing together with an MPU-6050. I was able to reproduce the same Issue with a HTU21D Sensor.
My function "i2c_master_init()" consists of the following startup tasks:
My sequence to make those "dummy" requests is the following:
After this "dummy" sequence I can normally talk to the slave device:
On this image you can see an overview of the spike (Trigger point) and the followed byte write's:
Here is a closeup of the spike:
This is a closeup of the "dummy" request + data write. You can clearly see that on the "dummy" request the sensor doesn't work properly (confused state machine due to the spike) and afterwords work perfectly with it's address: