ESP32 I2C power/distance problem?

[Archibald]

Things will look nice and sharp on your logic analyser because it only detects 'low' and 'high', nothing in between.

With my 5m of cable and oscilloscope, I am seeing clearly the shape of the rising and falling edges, at least master-to-slave signals. However, because of all the data flying around with the I²C scanner, I am not able to examine the pulse train in detail (it does not help that my oscilloscope's delayed timebase is not working).

Especially as I had reduced the clock to 50kHz, looking at the rising and falling edges, I think the bus should have been able to work happily with 5m of cable.

From what I could make out from the overlapping traces on my oscilloscope screen, I was surprised to see that the clock signal did not appear as a simple square wave: the period of its cycles was not always 20μs.

I am now addressing my slave on the end of 5m of cable using Arduino code and I can see the response coming back on the oscilloscope. I have not yet tried to read what it's sending. At least so far it tends to demonstrate that I²C can work over that cable with an ESP32.

My hunch at present is that the ESP-IDF I²C driver is not allowing sufficient data setup/hold times (in one or both directions) so even a small cable capacitance stops the bus working (even at reduced clock rate). But it's only a hunch.

P.S. Where have you read that "the I2C bus on the esp32 is not stable without some modifications"?

[Hexman64]

That was here: https://github.com/espressif/arduino-esp32/issues/912
See what 'stickbreaker' writes.

[antonyc]

Things will look nice and sharp on your logic analyser because it only detects 'low' and 'high', nothing in between.

With my 5m of cable and oscilloscope, I am seeing clearly the shape of the rising and falling edges, at least master-to-slave signals. However, because of all the data flying around with the I²C scanner, I am not able to examine the pulse train in detail (it does not help that my oscilloscope's delayed timebase is not working).

Especially as I had reduced the clock to 50kHz, looking at the rising and falling edges, I think the bus should have been able to work happily with 5m of cable.

From what I could make out from the overlapping traces on my oscilloscope screen, I was surprised to see that the clock signal did not appear as a simple square wave: the period of its cycles was not always 20μs.

I am now addressing my slave on the end of 5m of cable using Arduino code and I can see the response coming back on the oscilloscope. I have not yet tried to read what it's sending. At least so far it tends to demonstrate that I²C can work over that cable with an ESP32.

My hunch at present is that the ESP-IDF I²C driver is not allowing sufficient data setup/hold times (in one or both directions) so even a small cable capacitance stops the bus working (even at reduced clock rate). But it's only a hunch.

P.S. Where have you read that "the I2C bus on the esp32 is not stable without some modifications"?

Ok, I can see what you mean, but that's not my understanding of it! The 'nothing in between' isn't nothing, it either gets pulled up or down and I think that's ok because if the logic analyser pulls it up or down, the device 'should' also do the same thing and we'd be able to see the problem. I can see what you're saying about the rising and falling edges now though. Ofcourse, to a logic analyser, the top 'half' of a rise and fall will be HIGH and the bottom 'half' of a rise and fall will be LOW.

I've seen this sort of problem before with the ESP32. A few weeks ago, I fixed Modbus, TIA485. It was because the timing of the ESP32/libraries was just messed up.

It looks like I'm going to have to look into the wire library.

[antonyc]

That was here: https://github.com/espressif/arduino-esp32/issues/912
See what 'stickbreaker' writes.

I've noticed this but I didn't want to mess about with the core.

I think for what it's worth, it's now time for me to give it a try.

Let's see what happens.

[Archibald]

Here is what I'm seeing on my old CRT oscilloscope when transmitting from the ESP32 . . .

I2C trace.jpg (46.6 KiB) Viewed 15919 times

The upper trace is the SCL clock, which is high before the oscilloscope trigger. The small blip at the start of the clock signal is deceptive: it's from capacitive coupling within the cable from SDA going low. You can see the clock is being pulled low very fast by the ESP32 but it is much slower being pulled high by the 1kΩ pull-up resistor on SCL.

The lower trace is the SDA data: 7-bit address 1101000 (0x68) followed by 'read/write' bit (high=read) and a further clock pulse for any acknowledgement from the slave. You can clearly see the effect of capacitive coupling within the cable from the clock signal to the data data while the data is pulled high by the SDA resistor. The voltage is going above 3.3V, albeit only for a fraction of a microsecond, but that may be something to be concerned about if driving a longer cable with greater capacitance. It's a good reason to keep the pull-up resistor low when using a length of cable.

If I change the slave's address to 0x68 I can see the acknowledgement and other data being received.

This is working at over 100kHz.

We should remember that I²C was designed only for interconnecting integrated circuits within close proximity to one another.

[antonyc]

Here is what I'm seeing on my old CRT oscilloscope when transmitting from the ESP32 . . .

I2C trace.jpg

The upper trace is the SCL clock, which is high before the oscilloscope trigger. The small blip at the start of the clock signal is deceptive: it's from capacitive coupling within the cable from SDA going low. You can see the clock is being pulled low very fast by the ESP32 but it is much slower being pulled high by the 1kΩ pull-up resistor on SCL.

The lower trace is the SDA data: 7-bit address 1101000 (0x68) followed by 'read/write' bit (high=read) and a further clock pulse for any acknowledgement from the slave. You can clearly see the effect of capacitive coupling within the cable from the clock signal to the data data while the data is pulled high by the SDA resistor. The voltage is going above 3.3V, albeit only for a fraction of a microsecond, but that may be something to be concerned about if driving a longer cable with greater capacitance. It's a good reason to keep the pull-up resistor low when using a length of cable.

If I change the slave's address to 0x68 I can see the acknowledgement and other data being received.

This is working at over 100kHz.

We should remember that I²C was designed only for interconnecting integrated circuits within close proximity to one another.

Ok, that looks healthy to me... I've now got this new library thing installed, so I'm going to flash it over now.

Antony

[antonyc]

That was here: https://github.com/espressif/arduino-esp32/issues/912
See what 'stickbreaker' writes.

I've noticed this but I didn't want to mess about with the core.

I think for what it's worth, it's now time for me to give it a try.

Let's see what happens.

Since using these library files, my sensors have been working for a record time of 90 minutes!

[Hexman64]

I would have wished for even clearer rectangle signals. As I'm only reading a RTClock and writing to the displays every second, I would not mind if that would run at only 10kHz, but like I said, I cannot observe any change on my scope after using Wire.setClock(10000);
On the other hand, the problems on the bus do not come from bad signal quality anyway.

Good that these changes seem to work for you!
Any idea if you could still use Wire.h on a Nano now? Or would you have to copy the originals back every time?

I added a secret menu in my project to show me an I2C-reset-counter and at what time the first 10 resets happened.
It goes from every 30 minutes to not a single problem in >8 hours.
But I'm only operating the bus once a second, so if you are stressing yours all the time, running for 90 minutes might really mean it's a working solution.

[antonyc]

I think these files have resolved the problem!

[antonyc]

Just to confirm, it works with the replacement files!