• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 33 subscribers
  • Views 2388 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Issue using tm4c123 as I2C slave

Andrew Olson1
Prodigy 105 points

I'm using the TM4C as an I2C slave.  I'm running into an issue where the TM4C decides to release the SDA line in the middle of a transfer so my host controller reads invalid data.  This is causing major glitches in my control system.

The TM4C is coded with a standard I2C register format.  Each register is 32bits so it requires 4 bytes to be sent back.  I uncovered the issue because on one of the registers I read is only 16bits so i zero out the upper bytes however when I scope SDA I sometimes see the line go high in the middle of one of the upper bytes and sometimes one of the lower bytes.  

Under what conditions would the TM4C release the SDA line during a transfer?  The TM4C is not hung because I can continue to read/write it and it continues its control functions.

Summary

  • I2C0 set up as slave
  • Releases SDA randomly during 4 byte transfer(happens in any of the four bytes) when addressed as slave transmitter.
  • Usually recovers at the next transfer
  • Host reads at ~200Hz
  • Happens at a non-deterministic rate
  • Happens at both 100khz and 400khz SCL speeds

Thanks

  • 0
    TI__Guru 59540 points
    Hello Andrew,

    Is this happening in the middle of one of the bytes or is it happening on the byte boundaries? To fully understand what might be happening, we need to understand the state of both the SDA line and SCL during and the transition to high and after held high. If you have scope plots of this, it would be helpful.

    A few cases where the SDA line might go high is during the acknowledgement clock pulse. This pulse is generated by the master where the master will release the SDA line during the ack clock pulse. In turn, the slave should drive the SDA low during the high period of the the ack clock pulse. When a slave doesn't ack the slave address, the SDA line will remain high and the master will issue a STOP condition to abort the transfer.

    Likewise, when the master is on the receiving end in a transfer, it must signal the end of data to the slave by not generating the ack on the last byte that was clocked from the slave. The slave should then release the SDA line to allow the master to generate a STOP or repeated START condition.

    Since your scenario is a transmission from the slave to the master, I would presume that the slave is waiting on the STOP condition for the byte just transfered if you are seeing SDA going high at the end of a byte. If it is mid-byte, we will need to dig a little further.
  • 0 in reply to Chuck Davenport
    Prodigy 105 points
    Hello Chuck, thanks for the reply.

    I've observed it happening in the middle of bytes. The master still thinks that a transfer is going on and continues to send SCL pulses and ACKs each byte. We've looked at the scope plots and they look fine. Nothing jumped out at us that would indicate a bad/invalid edge transition. We should be able to get some scope plots if you think it is necessary.

    Some other information that I forgot to mention previously. We have a total of 3 TM4C slaves on this bus and they all run the same code. We had a ground loop/isolation problem to the enclosure that we fixed and that helped. The 'glitches' went down in frequency but didn't go totally away.

    Let me know what other info I could provide.
  • 0 in reply to Andrew Olson1
    Guru 47900 points
    In accord w/"KISS" would it not prove worthwhile to (temporarily) break the connections to (two) of the TM4C slaves - just to "be sure?"

    Unstated is the length of separation between master & TM4C slaves - and if noise sources are nearby & active. (all such should be removed from the playing field initially - to see if they are the disruptors!)

    With multiple devices upon the I2C bus it is usual to lower the value of your two pull-up resistors. Even a very small value ceramic cap - placed @ each slave's I2C pins - has been noted to solve such issues...
  • 0 in reply to Andrew Olson1
    TI__Guru 59540 points
    Hello Andrew,

    Given you are seeing the issue increase/decrease with the frequency of the glitches, I am curious if you have made use of the glitch filtering capability of the I2C and, if not, can you give it a try to see if this helps your issue?

    This post has a fairly extensive discussion the glitch filters on the TM4C devices e2e.ti.com/.../423351
  • 0 in reply to Chuck Davenport
    Prodigy 105 points
    Chuck, correct me if I'm wrong but according to the TM4C datasheet and DRVLIB the glitch filter is only for master mode. My Tiva's in slave mode and I have a different processor(a Zync) as the master. Unfortunately the I2C glitch filter does not work in the zynq.
  • 0 in reply to Chuck Davenport
    Guru 47900 points

    Chuck Davenport said:
    Given you are seeing the issue increase/decrease with the frequency of the glitches

    Hi Chuck,

    We wonder how you've come to this conclusion.   (poster's made no such mention of increase/decrease w/frequency - instead he reports fairly equal occurrence @ both 100 & 400KHz I2C rates.)

  • 0 in reply to cb1
    Prodigy 105 points
    cb1,

    the slaves are daisy chained have roughly 3 inches between them. The total length is on the order of 15 inches. As I mentioned before we have scoped out at the last device and the traces looked fine; not much noise, clean edges, etc.

    We have done what you have suggested except adding the caps. I can talk with my electrical engineer about that possibility.
  • 0 in reply to Andrew Olson1
    Guru 47900 points
    Have you removed (temporarily) the 2 most distant TM4C slaves (via trace and/or cable cut) - and observed results w/just a "single" (closest) TM4C slave?

    As to scope - catching a single errant pulse w/the scope probe (loading) may not prove ideal...
  • 0 in reply to Andrew Olson1
    Expert 1030 points

    Andrew,

    You really need to isolate the other devices and walk before you run.   There are a variety of ways that your multi-slave arrangement  could be going wrong.  Debugging will go faster if you debug one problem at a time.

    You should also attach some of your I2C slave code for review, or devise an experiment where you can show that its right.   You haven't specified the data rate.   Since you have suspect signals, you need to run things at 100kHz until you have it all working well. 

    Good luck.

  • 0 in reply to cb1
    TI__Guru 59540 points
    cb1,

    From Andrew's Earlier Post:
    "We had a ground loop/isolation problem to the enclosure that we fixed and that helped. The 'glitches' went down in frequency but didn't go totally away."

    This statement led me to believe he was seeing glitches/noise on the network and as ground isolation improved the frequency of the issue diminished.
  • 0 in reply to Chuck Davenport
    Guru 47900 points

    I believe poster used "glitches" as shorthand for, "performance interruptions" - not as observed waveform irregularities.   My reasoning follows:

    From poster's yesterday (4:10) poster writing, "  We've looked at the scope plots and they look fine.   Nothing jumped out at us that would indicate a bad/invalid edge transition."

    Two now have suggested that poster "simplify" (i.e. employ KISS) by "cutting free" the 2 extraneous TM4Cs - focus/limitation most always speeds, eases, enhances the troubleshoot...