I2C SCL frequency 10% less than it should be at 400kHz

[ESP_igrr]

If you can point us to the code and a description of the setup (what kind of display we need to use), I'll pass this info along so that we can see if the hardware is generating invalid waveforms at some point.

[Scalpel78]

I just want to drop a line here. I'm also seeing similar problems like MartyMacGyver. In my case I'm using an I2C based IR-sensor. It works for a few minutes, and then the ESP32 looses connection with the device.

I haven't been able to troubleshoot this as much as MartyMacGyver has, but with my Saleae probe I'm also seeing a clock frequency which is deviating slightly from the expected 100kHz.

As a workaround I'm going to play around with changing the size of the pull-up resistors to see if that can bring the clock frequency closer to the expected 100kHz. In my project I just need I2C to be stable for 3 minutes, so maybe I'm lucky enough to keep it alive for that long.

My code is fairly basic; https://github.com/Scalpel78/Ghost/blob ... nsors/main

[MartyMacGyver]

If you can point us to the code and a description of the setup (what kind of display we need to use), I'll pass this info along so that we can see if the hardware is generating invalid waveforms at some point.

It's not so much the code that matters as the device under test does. A display gets far more traffic than a sensor, so the glitches are more obvious and occur much more quickly. Some kind of loopback test might work better (or it might not work at all) but I've not devised one yet.

It would be ideal if we were testing the same I2C device: something that can take a lot of I2C traffic, is obvious when it glitches, and which doesn't require interrupts (which can complicate things). I've got a few ideas though...

I just want to drop a line here. I'm also seeing similar problems like MartyMacGyver. In my case I'm using an I2C based IR-sensor. It works for a few minutes, and then the ESP32 looses connection with the device.

While I am concerned about the unusual sensitivity of I2C on the the ESP32 to load (it takes very little to make the output frequency vary, especially at 400kHz) I don't think that's the main issue.

Extra capacitance across between VDD and GND (47uF or so) would help rule out power-related issues (IR LEDs draw a fair amount of current).

I assume the sensor is being tested in isolation so no other i2c devices are present. I don't see pull-up resistors on the breakout board I looked at (http://www.robot-electronics.co.uk/file ... e02b_e.pdf) - what value of pull-up resistors are you using for this? (Typical value is 4.7Kohm).

Edit: One reference I looked at was https://github.com/NorbotNorway/TeensyAndGP2Y0E02B... I just noticed you're a contributor there so you're probably already aware of all this. Still, would be good to know what value you used in this case (1K is pretty strong IMHO but there's a lot that goes into that calculation - and as long as it's somewhere between 1K and 4.7K I don't think it really matters to the ESP32 problem).

If you rule out those potential problems and are still seeing the issue, then it gets more interesting. An advantage is your sensor is a lot like my display: just SCL and SDA. Since you're Teensy-savvy, is the same sensor rock-solid on that ARM device?

On a related note, I turned on my STM32-based Particle last night, running the OLED. It's been running test patterns for 10 hours and still no glitches (the glitches seen with the ESP32 are somewhat cumulative - once you get out of sync it tends to get worse from there).

[Hans Dorn]

I would also be interested to know exactly what hardware will cause I2C problems,
to see if I'm getting the same problems here.

I'm working on a little aquarium controller as a hobby project.
Nothing too fancy but it has to work 24 hrs/day, every day, or unpleasant things will happen.

Cheers
Hans

[Scalpel78]

I assume the sensor is being tested in isolation so no other i2c devices are present. I don't see pull-up resistors on the breakout board I looked at (http://www.robot-electronics.co.uk/file ... e02b_e.pdf) - what value of pull-up resistors are you using for this? (Typical value is 4.7Kohm).

Edit: One reference I looked at was https://github.com/NorbotNorway/TeensyAndGP2Y0E02B... I just noticed you're a contributor there so you're probably already aware of all this. Still, would be good to know what value you used in this case (1K is pretty strong IMHO but there's a lot that goes into that calculation - and as long as it's somewhere between 1K and 4.7K I don't think it really matters to the ESP32 problem).

I've tested the IR sensor by itself, and with other I2C devices connected as well. Lately I've been using my custom made PCBs when developing. They use 1k pullups.

Yes, the code you're referencing from NorborNorway is mine as well. It is from when I used Teensy in my autonomous RC car. Never had an issue with I2C there, but it's been quite unstable the little while I've been working on the transition to ESP32.

I've just designed a new revision of my PCBs the other day, and as soon as they get here from China I can test some more with I2C.

[Hans Dorn]

This part of the GP2 code could be a problem:

Code: Select all

	Wire.requestFrom(ADDRESS, 2);
	while (Wire.available() < 2);

If we consider the I2C on the ESP32 to be flaky, it's probably best to put a timeout on the while loop and retry from the beginning if not enough bytes arrive.

[Hans Dorn]

I just ran into the same issue (wrong data transferred over I2C) after adding a DS1624 temperature sensor to my setup.
Before, I only had a single PCF8574 used as an output.

With the single PCF8574 I didn't see any transmission problems, after adding the DS1624 I was seeing errors on both reads and writes.

This points to a software Issue, since the hardware did literally 100,000s of updates without problems before.


Long story short, looks like I2C suffers from the same bug as some other peripherals, mentioned in the errata sheet, issue 3.3.
https://espressif.com/sites/default/fil ... p32_en.pdf

I applied the same fix suggested there and moved the I2C base register accesses to a different address.
I2C seems to be working much better now. (knocks on wood).

I modified "esp32-hal-i2c.c" like this: (replace DR_REG_I2C_EXT_BASE with DR_REG_I2C_EXT_BASE_FIXED)

Code: Select all

// Copyright 2015-2016 Espressif Systems (Shanghai) PTE LTD
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at

//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

#include "esp32-hal-i2c.h"
#include "esp32-hal.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/semphr.h"
#include "rom/ets_sys.h"
#include "soc/i2c_reg.h"
#include "soc/i2c_struct.h"
#include "soc/dport_reg.h"

// #define DR_REG_I2C_EXT_BASE                     0x3ff53000
#define DR_REG_I2C_EXT_BASE_FIXED               0x60013000
// #define DR_REG_I2C1_EXT_BASE                    0x3ff67000
#define DR_REG_I2C1_EXT_BASE_FIXED              0x60027000


//#define I2C_DEV(i)   (volatile i2c_dev_t *)((i)?DR_REG_I2C1_EXT_BASE:DR_REG_I2C_EXT_BASE)
//#define I2C_DEV(i)   ((i2c_dev_t *)(REG_I2C_BASE(i)))
#define I2C_SCL_IDX(p)  ((p==0)?I2CEXT0_SCL_OUT_IDX:((p==1)?I2CEXT1_SCL_OUT_IDX:0))
#define I2C_SDA_IDX(p) ((p==0)?I2CEXT0_SDA_OUT_IDX:((p==1)?I2CEXT1_SDA_OUT_IDX:0))


struct i2c_struct_t {
    i2c_dev_t * dev;
#if !CONFIG_DISABLE_HAL_LOCKS
    xSemaphoreHandle lock;
#endif
    uint8_t num;
};

enum {
    I2C_CMD_RSTART,
    I2C_CMD_WRITE,
    I2C_CMD_READ,
    I2C_CMD_STOP,
    I2C_CMD_END
};

#if CONFIG_DISABLE_HAL_LOCKS
#define I2C_MUTEX_LOCK()
#define I2C_MUTEX_UNLOCK()

static i2c_t _i2c_bus_array[2] = {
    {(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE_FIXED), 0},
    {(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE_FIXED), 1}
};
#else
#define I2C_MUTEX_LOCK()    do {} while (xSemaphoreTake(i2c->lock, portMAX_DELAY) != pdPASS)
#define I2C_MUTEX_UNLOCK()  xSemaphoreGive(i2c->lock)

static i2c_t _i2c_bus_array[2] = {
    {(volatile i2c_dev_t *)(DR_REG_I2C_EXT_BASE_FIXED), NULL, 0},
    {(volatile i2c_dev_t *)(DR_REG_I2C1_EXT_BASE_FIXED), NULL, 1}
};
#endif

Cheers

[MartyMacGyver]

I'll give that a look - define "much better" though... are you seeing errors still, but fewer, or no problems at all (so far)?

[MartyMacGyver]

Hans,

Others have been having this problem as well and I shared your post with them. Thanks to your discovery, the problem may be resolved. An issue has been raised on Github regarding this: https://github.com/espressif/arduino-esp32/issues/286. You might want to subscribe to that issue on there to further track it.

I'm curious if you're seeing this issue with the ESP IDF or with Arduino-ESP32? A corresponding fix may be needed for the IDF.

[Hans Dorn]

I'll give that a look - define "much better" though... are you seeing errors still, but fewer, or no problems at all (so far)?

Well, since I just made the change, I didn't want to jinx it

It's now been running for 63000 seconds at a cycle time of 14ms = 4,500,000 updates so far, and I haven't spotted a single wrong temperature in my log.

I'd say, it works, period.


Cheers!