i2c_master_cmd_begin() and error code 263 (timeout)

[RobMeades]

What things might cause i2c_master_cmd_begin() to return a "timeout" error code (263)?

My understanding was that the timeout, in the sense of the parameter passed to i2c_master_cmd_begin(), is just a timeout on putting the I2C sequence into a queue internally so that it can be sent. Hence, if there is only one task calling i2c_master_cmd_begin(), there should never be a chance of a timeout.

We have code that runs happily on ESP-IDF (v5) on an ESP32 MCU talking to I2C devices; we have always passed 0 as the timeout value to i2c_master_cmd_begin() and never seen a single timeout. However, when we do the same with an ESP32S3 MCU we are seeing unreliability on the I2C interface and, if I print the error code from i2c_master_cmd_begin(), most of the time, when there is an error, it is 263 (sometimes it is -1, i.e. no ack, so the HW in question may not be 100%, but if my reasoning above is correct then nothing in HW could cause the 263 error code, only SW inside the MCU can). FYI, setting the timeout value to, say 100 ms, doesn't help, the outcome is the same.

Any help is appreciated.

[MicroController]

see viewtopic.php?f=13&t=33382#p113221

Don't know if the S3 is affected, but at least on some SoCs the I2C controller's internal state machine apparently can become hung if some "unexpected" signalling happens on the bus. The I2C driver accomodates for that by implementing an internal timeout mechanism which triggers after a certain time without response from the I2C controller; the driver then resets the I2C controller/state machine and returns a timeout error.

If a slave uses clock stretching this may also cause an error (not 100% certain if it's also returned as TIMEOUT), if the I2C controller's configured timeout for clock streching is too short.
You can experiment with i2c_set_timeout(...).

[RobMeades]

Ah, that's interesting, thanks for the swift response and the link. I'd kinda assumed that since i2c_master_cmd_begin() necessarily has to block until it has finished with the bus, that any glitch-handling stuff would be over by then, but maybe it is cleverer than that and does stuff asynchronously somehow or other under the hood? EDIT: or maybe whatever is adrift with the HW is somehow causing a state-machine error, while i2c_master_cmd_begin() is running, so the timeout error is just another expression of a HW issue?

I will indeed check the HW out, 'cos I need to see why the "no ack" case is happening.

The i2c_set_timeout() thing gets interesting with S3: I raised it here viewtopic.php?f=2&t=32281&p=110304&hili ... ut#p110304 that the timeout for S3 seems to have a maximum value of 380 nanoseconds, which isn't going to be any use for anything, but have had no comment on that yet.

[MicroController]

The i2c_set_timeout() thing gets interesting with S3: I raised it here viewtopic.php?f=2&t=32281&p=110304&hili ... ut#p110304 that the timeout for S3 seems to have a maximum value of 3.8 nanoseconds, which isn't going to be any use for anything, but have had no comment on that yet.

Yeah, think I read that. Unsatisfying... Maybe just default-set up I2C, then use i2c_get_timeout(...) to get the "default" value and try to scale it by some factor.

[RobMeades]

Hmm, yes: if I read the header file correctly I believe that the I2C timeout in HW is disabled by default.

The more I think about this the more I realize I just need to get a probe on the HW; improved visibility is always a more likely route to success. I will report back here on how this works itself out.

[MicroController]

Just looked at i2c_ll_set_tout(...), and the docs say:

Code: Select all

 * @param  tout_num The I2C timeout value needs to be set (2^tout in core clock cycle)

Which makes a little more sense (the 2**tout part); not sure which clock it actually refers to though.

[RobMeades]

I think we probably need an Espressif person to comment. I was looking at the SoC header for S3, which says that the register which i2c_timeout_set() ultimately writes-to is in APB clock cycles, not core clock cycles:

https://github.com/espressif/esp-idf/bl ... reg.h#L242

I think I might raise a Github issue about this, 'cos even if it's not a code problem it might be a documentation problem.

[andreko]

Hi, thanks for the post and the discussion so far. Actually I ran into the same problem yesterday. I have code using the I2C on a ESP32 without any issues. Now I switched to a a ESP32-C2 (ESP8684-DevKitM1 rev1.1) and encounter exactly the same problem.
I debugged into it and found out so far that it seems to be correlated to the number of bytes send in one I2C transaction. For example: I am using a 3rd party library to interface with the slave device. During initialization FW is loaded via I2C. The chunk size of the FW was set to 254 bytes, which worked well on the ESP32, but caused the timeout on the C2. When I changed the chunk size to 14 it also worked on the C2. Unfortunately there are other transfers in the library that I can not modify in size. So I am still stuck with the problem.
I would rule out the HW for now, because I am using dev boards only and except the C3 board it worked with ESP32.
Looking at the I2C with an LA it seems that the clocking simply stops and the slave drives the SDA low, I assume to ACK the latest byte transferred. See attached screenshot.
I will start experimenting with the i2c_set_timeout() function to check if it changes something in the behavior.

[MicroController]

Interesting. There seems to not be any clock stretching happening when communication stops, so probably not a time out related to that.

[RobMeades]

<There isn't a big enough smiley, just picture an unshaved old bloke smiling very broadly />

That's an _excellent_ contribution, thanks very much for posting. Nice to have more people in the boat .

You have got rather further than me in your investigations; yesterday I ordered a perfectly standard Espressif ESP32S3 board and so, when it arrives, hopefully today or tomorrow, I will set up something that is easy to probe and only uses reference Espressif HW in the process. Will post back here when I have something.