I2C Timeout Error on Apalis T30 under C++ / not under C#

Technical Support
, ,
1

I am using the latest version of TdxAllLibrary V2.0-20170524 and I have a strange problem. Under C++ I sometimes get a timeout error (or byte not acknowledged?) with I2c_Write(…) function. But not every time. Most of the time it works. So it seems to be a timing problem of the hardware…

But with C# on the same hardware with the same DLL (tested with release and debug version) I never get this error. Tested it for hours and I it never raised this error.
I use exactly the same settings (BitRateHz=10000, SlaveAddrSize=0x52, RegisterAddrSize=0) and do everything the same (open bus etc.).

So it doesn’t look like it’s a hardware issue. I see the DLLs for C++ and C# are not exactly identical (file size), probably there is a issue? Is this problem known?

Try tomorrow to reproduce this with another I2C slave on the Ixora board.

2

btw: under C++ I2c_SetConfigInt(…); raises an error (invalid parameter). Under C# this works.

3

Does the toradex I2C master implementation support clock-streching?

4

The Apalis T30 supports clock stretching. Please note that a clock stretch is driven by the slave device. The master’s task is only to actually stretch the clock if the slave requests it.

The C# implementation does nothing but call the native corresponding c function. The only difference is that there’s some additional overhead in the C# code to call the native c function.

There are some inconsistencies in your question, which could explain the effects you see:
You stated that the BitRateHz is 10000 ( = 10 kbps). Usually i2c operates at 100 kbps. Might this be a typo and explain the difference between c and c#?

I recommend to measure the i2c SDA and SCL signals with an analog oscilloscope. Do the signals look reasonably square-shaped? (check for both the c# and the c code)
For longer measurements a digital logic analyzer is sufficient.

A typical error on i2c is that the impedance of the pull-up resistors on SDA and SCL is too high, thus the rising edges are not fast enough. This might work at 10kbps, but not at 100kbps.
The acknowledge signal for written bytes is generated by the slave device. if the slave sees correct signals on the SDA and SCL lines, there is no reason why it shouldn’t acknowledge the byte.

Anyway, it would be helpful to get logic analyzer / scope measurements for the case when communication fails.

5

Thank you for the good answer.
10kbps is a typo, I meant 100kbps, which I used in both applications.

Try to find the cause with some more tests.