Hello Toradex Community,
I am currently working with a product that utilizes the Calibri T20 module, and I have observed an intermittent issue with the I2C clock. Occasionally, the I2C clock is pulled low for exactly 100ms. This does not happen frequently, but when it does, the duration of the low state is consistently 100ms.
I am particularly curious about the consistent 100ms duration. It seems to me that this could be related to an I2C read timeout, potentially returning an error code such as -1. Unfortunately, I do not have access to the source code to verify this hypothesis.
Could anyone provide insights into whether the I2C read timeout on the Calibri T20 is indeed 100ms and if it returns -1 upon timing out? Any additional suggestions or troubleshooting tips to further diagnose this issue would be greatly appreciated.
Thank you for your support.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
I understand you’re experiencing an I2C timeout issue on the Colibri T20. Let’s explore how you can address this.
The I2C timeout behavior is influenced by the bus frequency, and you can calculate the minimum timeout value using the formula:
Tmin = 10/FSCL
where FSCL is the frequency of the I2C clock (SCL). For instance, at a frequency of 400 kHz, which is the maximum for the I2C bus, the minimum timeout would be 25 μs.
If you’re observing a consistent low state of 100ms, this is much longer than typical I2C timeouts, indicating potential issues. Here are some steps you can take to troubleshoot:
-
Bus Arbitration Issues: Check if there are any arbitration issues. The I2C controller will set the IAL (arbitration lost) bit if arbitration is lost.
-
Bus Busy Status: Verify the status of the IBB (I2C Bus Busy) bit. This bit is asserted by a Start condition and deasserted by a Stop condition.
-
Unexpected Stop Conditions: Examine the bus for any unexpected Stop conditions during data transfer.
These steps should help you identify the root cause of the timeout issue. If you need further assistance, feel free to ask for more detailed guidance on specific aspects of I2C troubleshooting.
Best regards,
Toradex AI Assistant
It depends on how you’re accessing the I2C in your source code. If you’re using the Toradex SE libraries, you can specify a timeout value and other configuration parameters using the I2c_SetConfigInt() function.
Since you don’t have access to the source code, it’s difficult to determine the exact timeout value that was set. Also, the I2c_Write() and I2c_Read() functions return -1 in case of failure.
In my experience with the functions I2c_Init(), I2c_Open(), and I2c_SetConfigInt(), I have been unable to access the code directly. I am wondering if the default timeout duration for I2c_Read() is 100ms.
The issue I am encountering is that during I2C communication, the clock line gets stuck low. It recovers from low to high after 100ms. My initial thought was that this behavior is related to an I2C timeout, causing the bus to return to idle after the timeout period. However, I cannot explain the specific 100ms duration. Could it be that 100ms is the default timeout for the I2C read operation?
If not explicitly set, the default timeout period is 100 ms.
