I2C Probe Timeout on STM32G070 Revision Y with New ESP-IDF I2C Driver (Works on Revision B & Old Driver) (IDFGH-14869)

[BatuhanKaratas]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.5-dev-1998-gc71d74e2f8

Espressif SoC revision.

ESP32-S3 (QFN56) (revision v0.2)

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

CMD

Development Kit.

Custom Board

Power Supply used.

USB

What is the expected behavior?

Our ESP32-S3 processor is acting as an I2C master, and we have two different revisions of STM32G070CBT processors acting as I2C slaves. We are using the new version of the I2C driver, and we are testing with the "i2ctools" example project from the master branch.

When using STM32G070CBT Revision B, performing an I2C probe at address 0x51 results in a positive response, meaning the STM32 I2C bootloader is successfully detected and communicating as expected.

What is the actual behavior?

When using STM32G070CBT Revision Y, performing the same I2C probe at address 0x51 results in a timeout error instead of a successful response. The error message received is:

E (13891) i2c.master: I2C transaction timeout detected  
E (13891) i2c.master: probe device timeout. Please check if xfer_timeout_ms and pull-ups are correctly set up  

This timeout issue does not occur when using the old I2C driver, but it appears when using the new I2C driver.

Steps to reproduce.

1. Setup ESP32-S3 as I2C master using the new I2C driver.
2. Connect STM32G070CBT Revision Y to the ESP32-S3 via I2C.
3. Ensure the STM32G070CBT is in bootloader mode (STM32 I2C bootloader enabled).
4. Run an I2C scan or probe for address 0x51.
5. Observe the timeout error in the logs.

There is no crash, but the I2C probe operation fails due to a timeout.

This issue does not occur when using STM32G070CBT Revision B, but it does occur with Revision Y when using the new I2C driver.

Debug Logs.

E (13891) i2c.master: I2C transaction timeout detected  
E (13891) i2c.master: probe device timeout. Please check if xfer_timeout_ms and pull-ups are correctly set up

More Information.

• The STM32G070CBT I2C bootloader is expected to respond at 0x51 but does not when using Revision Y.
• The same STM32G070CBT Revision Y works with the old ESP-IDF I2C driver, so the issue seems to be related to the new driver.
• Both STM32G070CBT Revision B and Revision Y have identical hardware connections, meaning this is not a hardware wiring issue.
• We have verified that pull-up resistors are correctly set and that the ESP32-S3 is in the correct I2C master mode.
• The issue occurs only when using the new I2C driver, so we suspect a change in ESP-IDF's I2C implementation might be affecting compatibility with STM32's I2C bootloader.

[ginkgm]

Could you provide your code that can produce this problem?

And btw, check if I understand correctly:

1. The issue only happens when new i2c driver AND rev Y. Not happening when using legacy i2c driver OR rev B.
2. Both rev B and rev Y should respond to 0x51.

Could you also provide the waveform captured by a logic analyzer? When we can't figure out what happen, we need to make sure whether ESP is sending correct command and the slave really reply with an ACK.

[mythbuster5]

Check your online data please. I2C transaction timeout detected this log indicated your scl line has been stretched somehow.

[BatuhanKaratas]

@ginkgm yes, the problem is exactly as you described.

In this test, I used the new I2C driver along with the i2ctools example code, where I increased the I2C timeout. The source code used is as follows:

void app_main(void)
{
    esp_console_repl_t *repl = NULL;
    esp_console_repl_config_t repl_config = ESP_CONSOLE_REPL_CONFIG_DEFAULT();

#if CONFIG_EXAMPLE_STORE_HISTORY
    initialize_filesystem();
    repl_config.history_save_path = HISTORY_PATH;
#endif
    repl_config.prompt = "i2c-tools>";

#if CONFIG_ESP_CONSOLE_UART
    esp_console_dev_uart_config_t uart_config = ESP_CONSOLE_DEV_UART_CONFIG_DEFAULT();
    ESP_ERROR_CHECK(esp_console_new_repl_uart(&uart_config, &repl_config, &repl));
#elif CONFIG_ESP_CONSOLE_USB_CDC
    esp_console_dev_usb_cdc_config_t cdc_config = ESP_CONSOLE_DEV_CDC_CONFIG_DEFAULT();
    ESP_ERROR_CHECK(esp_console_new_repl_usb_cdc(&cdc_config, &repl_config, &repl));
#elif CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG
    esp_console_dev_usb_serial_jtag_config_t usbjtag_config = ESP_CONSOLE_DEV_USB_SERIAL_JTAG_CONFIG_DEFAULT();
    ESP_ERROR_CHECK(esp_console_new_repl_usb_serial_jtag(&usbjtag_config, &repl_config, &repl));
#endif

    i2c_master_bus_config_t i2c_bus_config = {
        .clk_source = I2C_CLK_SRC_DEFAULT,
        .i2c_port = i2c_port,
        .scl_io_num = i2c_gpio_scl,
        .sda_io_num = i2c_gpio_sda,
        .glitch_ignore_cnt = 100,
        .flags.enable_internal_pullup = false        
    };

    ESP_ERROR_CHECK(i2c_new_master_bus(&i2c_bus_config, &tool_bus_handle));

    uint8_t address;
    for (int i = 0; i < 128; i += 16) {
        printf("%02x: ", i);
        for (int j = 0; j < 16; j++) {
            fflush(stdout);
            address = i + j;
            esp_err_t ret = i2c_master_probe(tool_bus_handle, address, 250);
            if (ret == ESP_OK) {
                printf("%02x ", address);
            } else if (ret == ESP_ERR_TIMEOUT) {
                printf("UU ");
            } else {
                printf("-- ");
            }
        }
        printf("\r\n");
    }

    register_i2ctools();
	
    printf("\n ==============================================================\n");
    printf(" |             Steps to Use i2c-tools                         |\n");
    printf(" |                                                            |\n");
    printf(" |  1. Try 'help', check all supported commands               |\n");
    printf(" |  2. Try 'i2cconfig' to configure your I2C bus              |\n");
    printf(" |  3. Try 'i2cdetect' to scan devices on the bus             |\n");
    printf(" |  4. Try 'i2cget' to get the content of specific register   |\n");
    printf(" |  5. Try 'i2cset' to set the value of specific register     |\n");
    printf(" |  6. Try 'i2cdump' to dump all the register (Experiment)    |\n");
    printf(" |                                                            |\n");
    printf(" ==============================================================\n\n");

    ESP_ERROR_CHECK(esp_console_start_repl(repl));
}

I executed the i2cdetect command via the console.

Here are the logic analyzer captures:

Revision B:

Revision Y:

As @mythbuster5 pointed out, the SCL line is stretched with revision Y. However, interestingly, we do not experience this issue when using the legacy I2C driver.

[mythbuster5]

New driver uses totally different logic. So it's hard to imagine a stretch could happen during a device probe. May you try to add a line code in function i2c_master_probe?

Please try and give a feedback, thanks! @BatuhanKaratas

[BatuhanKaratas]

When I applied your suggested change, the probe completed successfully. Actually, the timeout parameter you mentioned already exists at the device level as follows:

i2c_device_config_t i2c_dev_conf = {};
i2c_dev_conf.scl_wait_us = 20'000;

If we incorporate this into the i2c_master_probe function as well, it will allow us to probe devices that implement clock stretching.