I2C Timeout

[gwh]

I am trying to use the SUB-20 (along with the SUB-20 tool) to act as an I2C master. What I'm finding is that, in my application, many of the I2C commands (reads and writes) are reporting an ErrorCode. My I2C slave device uses I2C clock stretching to cause the master to wait for the slave (i.e. the clock line is held low during the acknowledge bit until it is ready for the master to continue). It appears that if the slave holds the clock line for to long, the SUB-20 times out and produces the ErrorCode.

Is there a way to change the time-out period? Or, better yet, is there a way to turn off the time-out period?

[xol]

Hi,
What is your timeout?
Without timeout device can stuck so this is not a good solution but we can definitely increase it. Tell me how much?

[gwh]

According to the I2C specification there is no requirement that communications be handled in a certain amount of time. The spec. even specifically calls out how to handle situations where the slave requires more time to handle a communication - clock stretching (slave pulls clock low during Ack bit until ready to continue).

If a slave is holding the clock line low, there is nothing the Master can do to get it unstuck - thus there is no reason to have a time-out in this special case.

In the particular application that I am working with, there are instances where the slave holds the clock line for 10-30mS, there is one instance where it can hold it for ~500mS.

[xol]

You are right. Spec does not limit clock stretching timeout. And this is how our I2C module works. It waits until clock signal is released by slave. But we can not do the same on API side. API has to return timeout, otherwise i2c functions will simply stuck.

Nevertheless, I have prepared a special FW for you with increased I2C timeout. It is now about 5s.
As you are the first and only one who has asked for such feature, I think not to provide special configuration via API to control I2C timeout. At least for a while. Firmware file is attached to this post. Please update your SUB-20 device and let us know if it worked well for you. Thanks.

[gwh]

It is unclear what type of change you made in the firmware you list, but there is no difference in how it handles my situation.

When I issue a write which causes an I2C clock-stretch (tried with a 24ms & a 1000ms stretch generating message) I immediately get an "i2c status: 226" message in the GUI which, according to your documentation, means 'Arbitration lost in STOP'. Looking at the waveform for the I2C lines, I see exactly what I expect - normal I2C communication with the clock held low after the last byte's 9th clock pulse, until the clock-stretch time period is done, then the clock goes and stays high.

It is unclear from your previous post exactly what or how things are handled. Is the I2C error I'm seeing in the SUB-20 tool window originating from the module or the PC application. If the error is generated by a timeout in the PC application then there is no way an update to the module code will help me. If the error is being generated by a timeout in the module code then your modification does not seem to have affected this timeout period.

After looking at things in more depth, I can see the lengthened timeout when using a read command. It's just doing a write command that I continue to have problems with.

[xol]

Hi,
Timeout is generated in firmware. The firmware I have uploaded has the timeout increased up to 500ms.
Any chance you could post problematic transaction waveform?

[gwh]

Here are some depictions of the waveform and finally a screenshot.

I2C Transaction.PNG (114.43 KiB) Viewed 15554 times

Previously it was stated that the timeout was 5 seconds, but now you say 500mS. A 5 second timeout would be preferable, this should handle all future possibilities.

[xol]

Hi,
The 5sec is correct. Sorry.

From the waveform it is not clear where exactly the clock stretching begins. I assume that after last data byte 0x08 is written your slave is starting to hold the clock low? Is it correct?

[gwh]

That is correct.

[xol]

Hi,
Well this is a very strange place to stretch clock. Usually clock stretching happens before ACK or during data write.
I have extended STOP condition timeout as well. Please try attached firmware.