TM4C1290NCPDT: I2C NACK issue

My friend - you've explained & detailed your issue so well - yet your subject line "TM4C: TM4C" conveys "NO HINT" of what your intriguing post contains!

Having been active here (and multiple other forums) for some time - such poorly implemented "Headlines" (Subjects, here) do NOT attract the "best/brightest!" due to the "blind/useless repetition" and complete absence of post's objective!     (this reporter does not meet that "qualification" - arrives out of curiosity & the attempt to assist...)

You may quickly/easily "Edit your Subject line by returning to "edit" that opening post - and creating a more "artful & descriptive Headline!"    (i.e. MINUS such "brain-dead" repetition ... such ALWAYS helps - just as adding "Urgent" insures FEW will "read your post!"

To your topic - I don't recall that such, "Reset & Initialize" ... "After every single operation" is required.     At least for our LX4F (several K units in the field) and our 4C123 (just under 200) we do NOT follow such "after every" protocol.     (while it cannot hurt - it is cumbersome)     

Might your board suffer "Power Supply Issues" or severe noise - either of which may render the MCU's I2C module - or Slave - (somewhat) confused?     In addition - our LONG experience - teaches that relying upon MCU's internal pull-up Rs proves, "Fool's Gold" - REAL (external) pull-ups perform FAR BETTER & PROVE ROBUST!       (MCU pull-ups are necessarily "high in value" - cause signal reflections & rounded edges - neither good - and EASILY AVOIDED!)

You don't provide the "Number of such boards" which present w/this issue - that's important - is it not?     (guards against dreaded, "Single Board Anomaly")

Is it possible that the particular EEPROM you've chosen proves causative - have you substituted others - as "eased/quick" confirming check?     We have used I2C for similar (external EEPROMs, ADCs, Temp Sensors, and GPIO Extenders) and thus far - have found NO NEED for "Reset & Initialize" after each/every I2C transaction!

Sorry sir,
As I was out of office I am not able to reply quickly and forgive me for the subject line as I am new this forum.

Regarding your reply for the problem: The power supplies are not an issue as other peripherals are working fine.
External pull ups are already provided. Not relying on the internal pull ups.
At present for the pilot quantity there are 7 devices and all the 7 devices faces the same problem.
I have tried with different EEPROM same problem persists.

The reset and initialize operation is not required every time, it is required only if an error occurs. Otherwise if there is no error then the read/write operation works fine without ant reset/ initialize.

Thank you - you note the power supplies as, "Not being an issue" - yet are "other peripherals" likely to be "as sensitive" as "I2C ones?" (which are "famed" for sensitivity to noise issues...)

You don't note the "frequency" of such disturbance. (i.e. is it once out of 20, 50, or 100 I2C transactions?)

How many devices share the I2C bus? What is the greatest distance between MCU and (most distant) I2C Slave? Is that (most distant) device the one which "errs" most often?

Are there "high speed traces" running near & parallel to your 2 I2C signal lines? What about "noise" or "power switching" - which may cause spikes & transients (both known to impact I2C and/or other "sensitive" inputs.)

And - as always - scope caps taken very near to the "most distant" I2C Slave would prove of high value...

Hi db1,
Thanks for providing all the good debugging tips. I like your tips about checking the power supply and noise. If the slave is prone to reply NACK then it may indicate that the voltage level on the SCL/SDA may not meet the slave's input threshold voltage or the some spikes caused the slave to misinterpret as a SCL cycle. It will be also good to know if the described I2C problem is only present at high speed (400k) or even at standard speed (100k).

Peripherals like SPI is used for the memory interface , the EPI interface for the LCD, USB communication with PC all are working fine.

The frequency of disturbance is like once the device gets communication error from the very next operation it malfunctions. For ex.: if I perform 1000 successful operation then there is no problem at all, but if any time a communication error is generated then it starts to malfunction.
At that time i used to restart the device and everything works fine , so I decided to reset the I2C module and initialize which resolved my issue.

The I2C is dedicated to a single device. The greatest distance between MCU and I2C slave is 0.75 Mtr. Every device is having the same issue.

No such high speed traces are running parallel to I2C signals. When I traced the signals in CRO not found any noise issue. Just not getting perfect square wave because of the capacitive effect, otherwise the voltage levels are far better.

I am ok with the reset and initialize operation every time which I have implemented in the software, but the only thing I am most concerned is that doing reset and initialize every time will reduce the life cycle of I2C module???

Here I don't think that it is a speed issue, I am using the 400k speed, but If I perform 1000 successful operation there is no problem , but a single error operation malfunctions the next operations.

Jijo Thomas6 said:

The I2C is dedicated to a single device.    The greatest distance between MCU and I2C slave is 0.75 Mtr.     Every device is having the same issue.

Some clarification required: you first note "single I2C device" - but then use the words, "every device" (has the same issue!)      When you speak to "every device" might you mean, "Other identical Boards?"   If not - I cannot tell if there is just one I2C Slave on your board...

The fact that you are 0.75 meters (I2C separated) - and running 400KHz (noted in a separate posting) - to me - provides a strong indicator that this "combined" Distance & Speed proves the (likely) cause of your issue.     

One thing (may) save you - even at that "excessive distance" and "very high speed!"      That would be "your use of the MCU's internal pull-up resistors" - if used - your "replacement w/4K7-10K EXTERNAL resistors" - may "Save your day!"      Although still - shorter separation & lower speed can ONLY HELP!

As always - when such troubles arise - moving to slower speeds (and where possible) shorter and more direct MCU <- > Slave separation - increases the robustness of your I2C transactions!     Note that your high speed is negated by the "too often" requirement to "sit idle" while you execute (repeated) Peripheral Resets...