ESP32s3 i2c baud rate changing

[billdi]

I'm trying to use I2C 0 at a slow 5kHz baud rate, but I'm finding that I only get a few transmissions at the correct baud rate and then it suddenly increases to 40kHz for the remainder.

To try and track it down I put this code at the top of app_main() - the rest of my code is still in the build but it never gets a chance to execute, so I think it's pointing the finger at ESP-IDF?

Code: Select all

#include "driver/i2c.h"
void app_main(void)
{
    static const char *TAG = "app_main";
#define I2C_EXT_SDA_GPIO 14
#define I2C_EXT_SCL_GPIO 21
#define I2C_EXT_SPEED 5000
#define EXTERNAL_I2C_CHANNEL I2C_NUM_0
#define CELL_ADC_ADDR 0x48

    const i2c_config_t conf0 = {
        .mode = I2C_MODE_MASTER,
        .sda_io_num = I2C_EXT_SDA_GPIO,
        .scl_io_num = I2C_EXT_SCL_GPIO,
        .sda_pullup_en = GPIO_PULLUP_DISABLE,
        .scl_pullup_en = GPIO_PULLUP_DISABLE,
        .master.clk_speed = I2C_EXT_SPEED,
        .clk_flags = 0,
    };
    i2c_param_config(EXTERNAL_I2C_CHANNEL, &conf0);
    i2c_driver_install(EXTERNAL_I2C_CHANNEL, conf0.mode, 0, 0, 0);

    while (1) {
        uint8_t buf[3];
        buf[0] = 1;
        buf[1] = 0XCC;
        buf[2] = 0x5A;

        esp_err_t res =
            i2c_master_write_to_device(I2C_NUM_0, CELL_ADC_ADDR, buf, 3, 10);

        vTaskDelay(1);
    }

I'm running this with no slave connected so there's no Ack bit. With that I get 10 Tx at the correct 5kHz, rest are 40kHz.
In other tests I noticed that the number of correct Tx seems to depend on the amount of bytes in the buffer passed to i2c_master_*()

I'm using ESP32-s3-wroom and ESP IDF v5.1.2 - I could update if it'll help but feels like it's unlikely this could have gone unnoticed and Google didn't help so thought I'd ask first...

Thanks!

[billdi]

Just a quick post to save others wasting time.
I got an email from Espressif suggesting it might be a known issue in v5.1.2 that was fixed in v5.2; I'm going to update and get back to you.

[aliarifat794]

you can try I2C_SCLK_SRC_FLAG_AWARE_DFS to see if it makes any difference in maintaining a stable clock rate.

[billdi]

Thanks for the info. In the end I figured I might as well jump to v5.3.1 seeing as I had to do a bunch of verification either way.
That did solve it; it turns out the i2c driver was completely refactored in between.

One thing did catch us out - we started to get timeout errors on the bus. On digging it seems that the meaning of the timeout changed during the refactor - it used to be RTOS ticks and now it's ms. Looks like the old APIs didn't account for that.

Anyway with recalculated timeouts we're all good.