I2C Errors not detected

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User10696
Level 4
Level 4
First solution authored
I have written a test program with DAVE 4 that uses I2C interfaces on an XMC4500.
When there are no problems with the hardware, everything works correctly, but if the hardware has a problem (pull-up missing for example) the program hangs.

I use the I2C_MASTER_Transmit() function to send the data and then wait until it is not busy, using I2C_MASTER_IsTxBusy(). In the case of a bus error, it just remains busy for ever! I have tried looking at the status but I cannot find any status that shows this error.

How can I write a robust program that works with hardware errors? There must be some way to detect this situation and deal with it in the software. Which bit of which register do I need to look at?
0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
User14604
Level 4
Level 4
First solution authored
No, you are definitely not.

We had similar problems, most of them originating from noise on the line generated by an external power supply, which made the I2C connection stall. To work around it, we added two things
1. Do not wait forever to read / write, but instead define a timeout and return from the method in case of a timeout.
2. Let the enclosing software layer handle too many timeouts by resetting the I2C communication completely.

Attached you'll find a simple example for interfacing the TMP275 temperature sensor. It is not complete, but probably not too hard to understand.

Best regards,
Ernie

View solution in original post

0 Likes
5 Replies
User10696
Level 4
Level 4
First solution authored
Am I the only person using I2C?
How can I write a robust program? I need to know if the bus is blocked, or the transmit is not finished.
0 Likes
lock attach
Attachments are accessible only for community members.
User14604
Level 4
Level 4
First solution authored
No, you are definitely not.

We had similar problems, most of them originating from noise on the line generated by an external power supply, which made the I2C connection stall. To work around it, we added two things
1. Do not wait forever to read / write, but instead define a timeout and return from the method in case of a timeout.
2. Let the enclosing software layer handle too many timeouts by resetting the I2C communication completely.

Attached you'll find a simple example for interfacing the TMP275 temperature sensor. It is not complete, but probably not too hard to understand.

Best regards,
Ernie
0 Likes
User11773
Level 4
Level 4
First like received First solution authored
Turn off FIFOs with I2C.

What I’ve found while testing here on my board is that the unit will hang (and reset via the WDT), even with no communications activity or anything. If so, a solution to that seems to be to disable the FIFO’s for the I2C app. In the I2C ISR there is a potentially infinite loop in the generated code where it waits for the FIFO to be empty (if FIFO mode is enabled). Why it gets to the point where it fails to ever pass- I don’t know. I can look at that in more detail if you want, but if this is the problem you see then disabling the FIFO’s is probably the most straightforward solution.
0 Likes
User10696
Level 4
Level 4
First solution authored
I do not know if this is your problem, but I know there is/was a bug in the XMClib function to set the RX FIFO trigger level. The TX trigger level get changed as well.

I cannot remember all the details, but I think the FIFO was disabled before changing the limit. Reading the reference manual makes it seem necessary to disable the FIFO first, but this is not the case and causes the side effect. I copied the XMClib function and removed the disable and had no more problems.
0 Likes
User11773
Level 4
Level 4
First like received First solution authored
I generally use Dave apps. Then modify from there as needed.
I'm use FreeRTOS too.
I was getting random crashes that where very hard to track down. When I turned off I2C FIFOs, the random crashes went away.
Also, I use 1 task - 1 hardware entity. I don't use multiple tasks access same hardware and using mutex to control access.
0 Likes