i2c instability
i2c instability
I've been trying to use the I2C for a number of digital sensors. They're generally 3.3V-5V capable, and for the 5V ones, I have a mosfet-based bi-directional level shifter.
Just testing the port using the arduino i2c scanner example and have it compiled+flashed via the Arduino IDE using the latest Arduino-ESP library. I've also tried the esp-idf and modified the i2c example to generate the same queries. In both cases the code basically goes through every address and simply writes the 7 bits, write bit, and then sees if there's an ACK from a slave on the bus responding to that particular address. Probing SDA/SCL without anything attached shows the correct i2c stream generated (using a bitscope micro as a logic analyzer).
However, as soon as I start trying the actual sensors, I get extremely unreliable behaviour: some devices get polled correctly, but after replugging it, the i2c port may stop working. Some devices will cause the ESP to hang completely, while others don't respond. I've tried different combinations of internal pullu-ps only as well as disabling them and using external pullups. Also tried with and without level shifting. It seems like the port is either very sensitive hardware-wise, or the i2c driver has a lot of places where it hangs/stops working. Sometimes the code still runs, but I don't see any signals on scl/sda...
My goal was to build a general purpose interface that allows plug-and-play for various i2c based sensors, but it looks like the current state of the i2c implementation might not be developed to that point yet? In contrast, I've used the same sensors (and just tried the scanning sketch) on an Arduino Uno and it works flawlessly. Also no issues running them with a Raspberry Pi using the bi-directional level shifter...
Comments/suggestion welcome!
Just testing the port using the arduino i2c scanner example and have it compiled+flashed via the Arduino IDE using the latest Arduino-ESP library. I've also tried the esp-idf and modified the i2c example to generate the same queries. In both cases the code basically goes through every address and simply writes the 7 bits, write bit, and then sees if there's an ACK from a slave on the bus responding to that particular address. Probing SDA/SCL without anything attached shows the correct i2c stream generated (using a bitscope micro as a logic analyzer).
However, as soon as I start trying the actual sensors, I get extremely unreliable behaviour: some devices get polled correctly, but after replugging it, the i2c port may stop working. Some devices will cause the ESP to hang completely, while others don't respond. I've tried different combinations of internal pullu-ps only as well as disabling them and using external pullups. Also tried with and without level shifting. It seems like the port is either very sensitive hardware-wise, or the i2c driver has a lot of places where it hangs/stops working. Sometimes the code still runs, but I don't see any signals on scl/sda...
My goal was to build a general purpose interface that allows plug-and-play for various i2c based sensors, but it looks like the current state of the i2c implementation might not be developed to that point yet? In contrast, I've used the same sensors (and just tried the scanning sketch) on an Arduino Uno and it works flawlessly. Also no issues running them with a Raspberry Pi using the bi-directional level shifter...
Comments/suggestion welcome!
Re: i2c instability
Do you have a $10 logic analyzer in your possession? I have found these to be invaluable when tracking down I2C puzzles and whole heartedly recommend one. With one of those, you can look at the SDA and CLK lines and unambiguously see what is actually happening.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: i2c instability
Yes, I have a bitscope micro and using the Logic software (it's more like $100, but I'm not certain it is better than the cheaper $10 ones that exist for purely the logic analyzer feature... :p).Do you have a $10 logic analyzer in your possession? I have found these to be invaluable when tracking down I2C puzzles and whole heartedly recommend one. With one of those, you can look at the SDA and CLK lines and unambiguously see what is actually happening.
The main problem is that when it stops working, I get nothing on the bus! So not much to look at there... Unless of course the bitscope itself is doing something funky. But I'm not sure that is the case - often if I do a hard reset of the ESP32, I can get it to emit some valid and observable signals on the bus again.
Re: i2c instability
Can you clarify that the I2C apps you are trying to run are hosted within the ESP32 Arduino framework as opposed to the ESP-IDF framework? If so, then we probably want to move this thread to the Arduino sub-forum.
It has been my understanding that the I2C driver implementation for the ESP32 Arduino framework is not the same as the ESP32 I2C drivers found in the ESP-IDF framework.
It has been my understanding that the I2C driver implementation for the ESP32 Arduino framework is not the same as the ESP32 I2C drivers found in the ESP-IDF framework.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: i2c instability
I apologize for English. Google Translate
I had the following problem with I2C.
On my board I have the connector I2C, SPI, and IO.
When I plugged a cable ribbon on this connector, I2C completely dropped off, and
I had to be RESET.
If I plug the connector into individual cables, the I2C works properly.
I had the following problem with I2C.
On my board I have the connector I2C, SPI, and IO.
When I plugged a cable ribbon on this connector, I2C completely dropped off, and
I had to be RESET.
If I plug the connector into individual cables, the I2C works properly.
Re: i2c instability
I'm using both the IDF and Arduino library. For the Arduino version I'm using the scanner app. For the IDF version, I'm basing it on the i2c example application that calls the following scan function after the setup on the master is complete:Can you clarify that the I2C apps you are trying to run are hosted within the ESP32 Arduino framework as opposed to the ESP-IDF framework? If so, then we probably want to move this thread to the Arduino sub-forum.
It has been my understanding that the I2C driver implementation for the ESP32 Arduino framework is not the same as the ESP32 I2C drivers found in the ESP-IDF framework.
Code: Select all
static esp_err_t i2c_scan_addr(i2c_port_t i2c_num, uint8_t addr)
{
i2c_cmd_handle_t cmd = i2c_cmd_link_create();
i2c_master_start(cmd);
i2c_master_write_byte(cmd, (addr << 1) | WRITE_BIT, ACK_CHECK_EN);
i2c_master_stop(cmd);
int ret = i2c_master_cmd_begin(i2c_num, cmd, 100/ portTICK_RATE_MS);
i2c_cmd_link_delete(cmd);
return ret; // ESP_FAIL or ESP_OK
}
I'm not sure if what mgsnmp mentioned is related, but general instability is indeed what I'm seeing. Basically when it works everything looks fine, when it doesn't, its somewhat inexplicable...
Re: i2c instability
minor update: in case anyone stumbles across this, on the arduino-esp side, perhaps this could help in recovering the bus after something goes wrong...
i expect a similar solution exists on the idf side where one could call the lower level reset if things hang up. i haven't dug into the i2c libraries for the regular arduino boards but perhaps there is a lot of bus resets/re-inits built in between commands that make it look a lot more seamless, and prevents what looks like lockups when doing things like hot-plugging i2c devices. i also expect the arduino boards to be more robust hardware-wise, being able to perhaps handle different pull-up resistances etc. (for example, when i have 2 or three devices on an arduino uno, the scanner returns the corresponding multiple addresses. on the esp32, there are quite a few sensors that don't even show up individually)
not having extensive resources to dive deep into the issue, i leave it here as some thoughts that might inspire someone else to look into. i've since given up on using i2c on the esp32 for now...
i expect a similar solution exists on the idf side where one could call the lower level reset if things hang up. i haven't dug into the i2c libraries for the regular arduino boards but perhaps there is a lot of bus resets/re-inits built in between commands that make it look a lot more seamless, and prevents what looks like lockups when doing things like hot-plugging i2c devices. i also expect the arduino boards to be more robust hardware-wise, being able to perhaps handle different pull-up resistances etc. (for example, when i have 2 or three devices on an arduino uno, the scanner returns the corresponding multiple addresses. on the esp32, there are quite a few sensors that don't even show up individually)
not having extensive resources to dive deep into the issue, i leave it here as some thoughts that might inspire someone else to look into. i've since given up on using i2c on the esp32 for now...
Re: i2c instability
Has anyone solved the problem with the hanging MCP23017 on ESP32 and the Arduino IDE platform?
Re: i2c instability
There's an alternative Arduino-ESP32 'Wire' library here that is supposed to be better:
https://github.com/stickbreaker/arduino ... aries/Wire
https://github.com/stickbreaker/arduino ... aries/Wire
Re: i2c instability
Do you have 2 pull-up resistors on your SCL/SDA lines ?
Who is online
Users browsing this forum: Baidu [Spider] and 60 guests