I2C legacy driver works, new one does not (IDFGH-13576)

[RobMeades]

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.

master-c9df77ef (headrev as of 28th August 2024)

Espressif SoC revision.

ESP32 v1.0

Operating System used.

Windows

How did you build your project?

Command line with idf.py

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

CMD

Development Kit.

All, but in this case ESP32-WROOM-32

Power Supply used.

USB

What is the expected behavior?

We supply a library (ubxlib) which allows customers to talk to our (u-blox) GNSS devices. The I2C part of that code has worked with the old ESP-IDF I2C API for many years now and is tested constantly in a regression test system.

We are now trying to move to the new ESP-IDF I2C API but have not yet been successful: we see pretty much constant "I2C hardware timeout detected" being reported. The issue might be related to #14129 (also connected with talking to a u-blox GNSS chip, all of which may perform clock stretching) but that issue seems to have been marked as "done" with resolution "NA", hence raising this separately.

Using one of our simpler regression test cases, I have Saleae logs of a success case with the old ESP-IDF I2C API and a fail case with the new ESP-IDF I2C API; both are, unfortunately, too large to upload here (greater than 25 Mbtyes), hence posting screen-shots of the relevant bits.

We ask the GNSS chip (address 0x42) how much data it has to send by writing to register 0xFD with no stop bit and then reading back two bytes, like this (in the case below the GNSS chip has 0x012e bytes to send):

...then we read those [in this case 0x012e, so 302] bytes from the GNSS device:

This is with the old I2C API, all is good.

Here is the same case with the new ESP-IDF I2C API; on this occasion when we ask it the GNSS chip happens to have nothing to send, which is not a problem, all is still good:

However, when we ask it the next time something goes wrong, the write to register 0xFD never completes:

We retry, of course, and eventually it might work, but things are just terribly flaky, nothing works well enough for a retry to fix. The output on a terminal shows:

Our I2C code can be found here; compiled with the flag ESP_IDF_I2C_NEW_API_DISABLE it works, leave that flag off to use the new ESP-IDF I2C API and it fails as above. Sometimes it does work, an I2C transaction succeeds, but more often than not it fails.

As you can see we have set scl_wait_us to 10000 (so 10 ms), clock is 400 kHz (the same in both pass and fail cases), clock source is of course APB (the only I2C clock source for the ESP32 chip), intr_priority is 0, glitch_ignore_cnt is 7 as recommended, enable_internal_pullup is true (and the pull-ups must be sufficient as they work for the old-API case). We always set the transaction timeout to -1 so that it can have no effect.

What might we be doing wrong?

What is the actual behavior?

See above.

Steps to reproduce.

Connect a u-blox GNSS chip to an ESP32 and use the code here to run test gnssCfgBasic().

Debug Logs.

See above.

More Information.

No response

[AxelLin]

We are now trying to move to the new ESP-IDF I2C API but have not yet been successful: we see pretty much constant "I2C hardware timeout detected" being reported. The issue might be related to #14129 (also connected with talking to a u-blox GNSS chip, all of which may perform clock stretching) but that issue seems to have been marked as "done" with resolution "NA", hence raising this separately.

Above fix is available in master tree now, 8aee667 , you can verify it after updating your ESP-IDF.

[mythbuster5]

right see 8aee667

[RobMeades]

Thanks guys, a quick test with that commit included is looking good!

[GCTechnology]

I got same problem on ESP32 Lyrat 4.3 board. All the ADF examples will trigger these error messages. I'm starting to wonder if it's a hardware issue.

[GCTechnology]

I got same problem on ESP32 Lyrat 4.3 board. All the ADF examples will trigger these error messages.

[mythbuster5]

Did you update the idf version?

[GCTechnology]

Did you update the idf version?

Yep, I also post this issue at espressif/esp-adf#1281. Now I suspect it's a hardware problem.