I2C Master regression (IDFGH-12542)

[ammaree]

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.3-dev-3220-g9c99a385ad

Espressif SoC revision.

ESP32 rev 3

Operating System used.

macOS

How did you build your project?

VS Code IDE

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

None

Development Kit.

ESP32 WRover Kit

Power Supply used.

USB

What is the expected behavior?

I2C device discovery to work

What is the actual behavior?

I2C device discovery fail on ALL devices

Steps to reproduce.

Our code was working 100% on 6 different platforms configured with 2 ~ 6 different I2C devices per platform.

Using master up to 2024/03/18 all platforms all devices discovered and worked perfectly.

Having come back from leave, with NO changes to the code other than updating to latest master, all platforms fail trying to discover all devices. With the ESP-32 Rover devkit v4.1 test device only the first address (0x08) returns the correct status (ESP_ERR_NOT_FOUND) , no device found, all remaining addresses return ESP_OK

Debug Logs.

9.126 0 main i2c.master I2C hardware NACK detected
9.134 0 main i2c.master s_i2c_synchronous_transaction(833): I2C transaction failed
9.137 0 main i2c.master i2c_master_transmit(1035): I2C transaction failed
I2C -0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -a -b -c -d -e -f
0x: xx xx xx xx xx xx xx xx -- 09 0A 0B 0C 0D 0E 0F
1x: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
2x: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
3x: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
4x: 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
5x: 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
6x: 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
7x: 70 71 72 73 74 75 76 77

More Information.

No response

[ammaree]

@mythbuster5 guess this would be for your attention

[mythbuster5]

@ammaree Sorry by this. We have a testing here tests this similar usage https://github.com/espressif/esp-idf/blob/master/examples/peripherals/i2c/i2c_tools/main/cmd_i2ctools.c#L118 but it doesn't report anything wrong

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- 5b -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

May I check your code and check in which case this regression will happen?

[mythbuster5]

Seeing from log, it might not be probe interface? Is it possible to be _transmit ? If so, what about change return to break https://github.com/espressif/esp-idf/blob/master/components/esp_driver_i2c/i2c_master.c#L428

[ammaree]

const halI2C_Init_t halI2C_Init[halI2C_NUM] = {
  {
	.i2c_port = I2C_NUM_0,
	.sda_io_num = GPIO_NUM_26,
	.scl_io_num = GPIO_NUM_27,
	.clk_source = I2C_CLK_SRC_DEFAULT,
	.flags.enable_internal_pullup = 1,
  }
}

void halI2C_BusConfig(u8_t eCh) {
	IF_myASSERT(debugPARAM, eCh < halI2C_NUM);
	ESP_ERROR_CHECK(__real_i2c_new_master_bus(&halI2C_Init[eCh], &hI2Cbus[eCh]));
}

/***
 * halI2C_CheckAddress() - check if ANY type of I2C device is present at a specific address
 */
bool halI2C_CheckAddress(u8_t eCh, u16_t Addr) {
	int iRV = i2c_master_probe(hI2Cbus[eCh], Addr, i2cTIMEOUT_DEFAULT);
	IF_SL_ERR(debugTRACK && iRV == ESP_ERR_TIMEOUT, "Timeout B=%d A=x%X, check bus termination", eCh, Addr);
	return (iRV == ESP_OK) ? 1 : 0;
}

[ammaree]

Only 2 I2C devices in this specific config, DS2482 and DS2482 at addresses 0x18 and 0x19

The errors occur before any _transmit function in my code.

1. Initialise bus
2. Discover devices
3. 0x08 returns correct status (0)
4. 0x09~0x17 return incorrect status (1)
5. 0x18 & 0x19 return correct status (1) but assume this is by accident
6. 0x1A to 0x77 all return incorrect status (1)

[mythbuster5]

Haven't reproduced currently🤨. Mine code is very simple. And quite as same as yours I think？

    i2c_master_bus_handle_t bus_handle;

    i2c_master_bus_config_t i2c_mst_config = {
        .clk_source = I2C_CLK_SRC_DEFAULT,
        .i2c_port = 0,
        .scl_io_num = 27,
        .sda_io_num = 26,
        .flags.enable_internal_pullup = true,
    };

    TEST_ESP_OK(i2c_new_master_bus(&i2c_mst_config, &bus_handle));

    esp_err_t ret = ESP_OK;
    for (int i = 0; i < 0x7f; i++) {
        ret = i2c_master_probe(bus_handle, i, 20);
        printf("ret val is %x\n", ret);
    }

So...(1) Could you please use my code under esp-idf environment and check whether it works or not.
(2) There are pretty few commits this days. May you find which commit is the cause?

Actually i2c.master i2c_master_transmit(1035): I2C transaction failed this log seems from i2c_master_transmit. What the pure log about i2c_master_probe interface? @ammaree

[ammaree]

halI2C_BusConfig(eCh);
halI2C_GeneralCall(eCh, I2C_GENCALL_RESET_WRITE);
IF_EXEC_1(debugTRACK && ioB1GET(ioI2Cinit), halI2C_BusScan, eCh);

[mythbuster5]

Checked one more time. Still doesn't reproduce the issue. Poke me if more clue has been found~~

[ammaree]

Have tested using i2c_tools example, works. Will test further