I2C timing issue in i2c_master.h. Legacy version works correctly. (IDFGH-13191)

[andychess]

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.2.2

Espressif SoC revision.

ESP32-C6FH4 (QFN32) (revision v0.0)

Operating System used.

macOS

How did you build your project?

Command line with idf.py

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

None

Development Kit.

Own Design

Power Supply used.

USB

What is the expected behavior?

i2c_master calls should return esp_err_t ESP_ERR_TIMEOUT when line is considered busy.

What is the actual behavior?

Unhandled exception occurs. Chip reboots.

Steps to reproduce.

1. Error occurs randomly when trying to read data from a ublox M10s GNSS module via i2c.
2. Issue is reported on the forum. https://www.esp32.com/viewtopic.php?f=13&t=32762

...

Debug Logs.

No response

More Information.

I reverted to the i2c.h legacy driver and the problem of timeouts still existed but did not cause a crash. I was also able to raise the max time out using i2c_set_max_timeout() which resolved the issue. I have been unable to find a similar function for i2c_master and can see from the hal files that the command is to be deprectated in the future. Please advise how to address this issue in the latest driver version.
PLEASE NOTE, this issue is not related to the timeout parameter in transmit and receive functions. These have no effect on the problem.

[mythbuster5]

see

/**
 * @brief I2C device configuration
 */
typedef struct {
    i2c_addr_bit_len_t dev_addr_length;         /*!< Select the address length of the slave device. */
    uint16_t device_address;                    /*!< I2C device raw address. (The 7/10 bit address without read/write bit) */
    uint32_t scl_speed_hz;                      /*!< I2C SCL line frequency. */
    uint32_t scl_wait_us;                      /*!< Timeout value. (unit: us). Please note this value should not be so small that it can handle stretch/disturbance properly. If 0 is set, that means use the default reg value*/
    struct {
        uint32_t disable_ack_check:      1;     /*!< Disable ACK check. If this is set false, that means ack check is enabled, the transaction will be stopped and API returns error when nack is detected. */
    } flags;                                    /*!< I2C device config flags */
} i2c_device_config_t;

scl_wait_us

[andychess]

Thanks for that. I tried setting scl_wait_us to 20000 and then 50000. It is still crashing sporadically. The longest period between crashes is about 20 read cycles and the shortest 2. Any idea what the maximum value for scl_wait_us
is?

[mythbuster5]

then is it possible to check data on line, and see how long scl has been stretched and why timeout happens

[andychess]

My logic analyser didn't show anything conclusive. The datasheet mentions the ability to stretch SCL to 20ms, but I haven't looked into this in great detail yet.
For me, the issue is that the new i2c_master driver does not handle the timeout correctly, in that it doesn't return ESP_ERR_TIMEOUT, as stated in the API guide and as is the case with the legacy version. Also, amending the scl_wait_us value, as you suggested, doesn't resolve the problem, although adjusting i2c_set_max_timeout in the legacy driver does.
The user in the forum post, linked in the report above, was working on the exact same code as I am, but had a slightly different problem. He was experiencing timeouts on one chip type and none on the S3. I believe he was using the legacy driver and so, presumably, didn't experience any crashes.

[andychess]

I just wanted to come back to this issue with some new information.
I eventually rolled back to the legacy i2c driver and all was working. Over the weekend, I updated the idf to 5.3 and decided to try again to update my ublox M10S driver to the new i2c_master.h implementation. I was still getting random timeout errors when trying to probe the device address. Previously, these had been unhandled errors and I could at least create a very dirty fix by repeating the call up to 20 times which would eventually work. However, when I went on to pass genuine traffic over the link, it would almost always time out and eventually crash as before.
Looking at the output from a logic analyser, I could see that the problem was that the SDA was remaining low after the transaction, which was being successfully acknowledged.
Some more research led me to this post: esp-rs/esp-hal#352 which describes a similar problem. When I followed the suggestion to change the line defining tout in the i2c_ll.h file for my chip version (ESP32-C6) from 10 to 20 cycles, this resolved the problem immediately.

The M10S data sheet states that the chip uses I2C clock stretching to 20 ms whilst the ESP-IDF Programming Guide suggests that the maximum expected clock stretch is 12ms.

Please could someone have a look at this and issue a fix. The issue is affecting at least two common devices and presumably others too.

To recreate: connect an ublox M10S via I2c and call i2c_master_probe for the dev Addr (0x42). Repeat up to 10 times to see the timeout failures.

Before changing i2c_ll.h

After change:

[mythbuster5]

Thanks for this clue, will take a look!