I2C/UART Interrupt conflict

Hi Amit,

Thank you so much for you quick response.  You verified what I assumed was occurring.  I'll look at your two proposed solutions and sort out what makes the most sense for our project.

Cindy

Cynthia Crutchfield said:

...main body of code...constantly processing I2C traffic...variety of peripherals.  Interrupted regularly due to UART data coming in.  Occasionally my I2C bus becomes corrupted-

While you've been gracious in awarding "two" Verifies - it's unclear if the solutions proposed (Amit's + mine) have (really) worked.   (of course it's far too early for you to have implemented...)

When my small tech firm hears/reads: "Constantly processing I2C traffic" we go on, "Red Alert!"   I2C maximizes connection convenience - but (IMO) too often fails as a robust communication method!   (and that's even recognized/admitted w/in I2C protocol via, "ACK/NAK.")   And - classic I2C is slow.  (as compared to other serial methods)

Now to your specific posting: I propose that you "shut-down" your UART data traffic - and run all else as normal - and compare/contrast the frequency of I2C data corruption under that (non-UART) condition.   Such should provide evidence of the UART's role (if any) in "data corruption."

When users "must" employ I2C - via multiple devices - we find that short, direct, guard-banded connection links lessen connection errors.   When board to board I2C links are required, proper shielded cables have helped immensely.   And - with multiple devices "on the I2C bus" - the selection & placement of the two "pull-up" resistors may prove critical.

Most always - lowering the I2C bus speed will yield error reduction - and enable greater separation between devices...

Hi!

Under normal conditions my system monitors temperatures and voltage levels on a regular basis- basically performing system health checks. All I2C connections are on a single board, and those communication links have been solid. This system runs reliably for days (I'm still running long-term tests to verify many, many days). Meanwhile, there are UART messages that come into my processor- both from sources external to our system and also from other processors that are internal to the system. Even if I disable the health checking when UART communication commences, there are times when the I2C bus becomes corrupted- I'm assuming this occurs when an I2C transaction is disrupted by the initial UART interrupt, and I do see the issue more with some devices than others. Losing the data from one transaction isn't that big an issue, but the actual I2C bus will at times be in an unrecoverable state, and health checks are unable to resume after the UART communication completes.

Thanks again for your feedback!

Cindy

Cynthia Crutchfield said:

...there are UART messages that come into my processor- both from sources external to our system...

Clearly this is a "swag" - we've noted "issues" when an RS-232 level shifter (either the component) or data traces is placed "too close" to I2C signal traces.   I'm keying here upon your statement of "sources external" (UARTs)  - which creates (some) expectation of the presence of such level shifters.

This vendor's "best" 129 MCUs employ a variable, I2C "glitch filter" (we don't use that MCU) and such may prove useful...

Hello Cindy,

As cb1 explained using the glitch filter may be an good way of checking (since we hardly know the layout of the board under use) if it is noise on the bus.

Regards
Amit

Hi Amit,

I believe my issue is that my UART traffic is interrupting my I2C transmissions.  I don't believe it's a hardware issue.  I think it's a software issue involving my I2C transactions occasionally getting interrupted midstream when a message come into one of my UARTs.  So I'm thinking I need to protect my I2C transmissions from these interrupts in order to get reliable I2C communications.

Thanks again for all your help!

Cindy

Hello Cindy,

Are you using while(I2CMasterBusy(I2Cx_BASE)) flag alone in the code or are you using

while(!(I2CMasterBusy(I2Cx_BASE)));
while(I2CMasterBusy(I2Cx_BASE));

Some details on the coding style would be useful.

Regards
Amit

Hi Amit,

I wanted to follow up with you- I debugged my problems.  First, I implemented an interrupt version of the I2C drivers as you suggested.  I also found I had another problem as well (possibly the only real problem).  My system runs constantly and does periodic health checking.  I also have a console for users to interact with the system.  My issue was that I wasn't alway protecting the internal health checking from being interrupted by console requests.  So at times, the internal health checking would get interrupted in the middle of I2C transactions.  So it took a bit of re-architecting to ensure that the two processing can co-exist and still run efficiently.  

So the short answer is that it was a problem I created for myself.  Thank you so much for helping me find and solve my issue(s)!

Cindy  :)

Hello Cindy

While I am glad you found the problem, I am rather uncomfortable with the fact the UART console interrupting an I2C Transaction causes the I2C bus to not respond. There must be something else like a Clock Low Timeout or the Slave having a clock low timeout detection which causes the actual issue. Without knowing that it may be still be a half baked solution.

Regards
Amit