XDIMAX Products Forum

This seems to work now in my application. - Thanks.

I tried your latest and found that it also does not work for me. When I checked the most recent waveform, the clock stretch was over 2 seconds (due to changes in the hardware that had to be compensated for in I2C firmware). So if you could provide a version that provides for 5 seconds of clock stret...

Just checked it out. Your latest fix seems to take care of a short clock stretch (22mS), but not a long clock stretch (1000mS). The SUB-20 GUI seems to return the error message very quickly.

I don't know if it is a strange place or not - but it is where Microchip does its clock stretching in hardware. Attached are two pages (in zipped pdf) from the Microchip data sheet showing the I2C waveform with clock stretching.

That is correct.

Here are some depictions of the waveform and finally a screenshot. 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.

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

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

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