• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 4635 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.

Error Service of I2C in TIVA TM4C1290NCPDT microcontrollers

smit majithia
Intellectual 605 points

Other Parts Discussed in Thread: TM4C1290NCPDT

Hello Sir,

Please anyone explain What Error Service mean in I2C Flow chart of TM4C1290NCPDT datasheet?

  • 0
    Intellectual 605 points
    and how to implement in the code for the same(Error Service)?
  • 0 in reply to smit majithia
    Guru 117855 points

    Would it not make (great) sense to "try again" when the error bit appears? Or - different levels of the "failed" I2C instruction may be launched.

    I believe the "error service" was made vague due to the variability of response which may be required. As one example - if "errors" repeatedly occur - an (effective) error service may see the (extreme case) "Powering down and reset of that I2C peripheral" - in the attempt to "clear a grave error condition." Clearly that's not required for sporadic errors - yet does illustrate why (some) wiggle room exists w/in that otherwise well detailed flow-chart...

    Implementation of that "multiple condition" code is a "bit much" to seek - don't you agree?

  • 0
    TI__Guru**** 244450 points
    Hello Smit

    I would recommend reading the I2C Application Note, Section 2 for you to first understand what Error means in the I2C

    www.ti.com/.../spma073.pdf

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 605 points

    Dear Amit,

    thanks for the reply,

    Can you please indicate which portion should i use for mainly error services?

  • 0 in reply to cb1_mobile
    Intellectual 605 points
    Thanks cb1_mobile.

    can you please explain what exactly I2CMasterErr will do ?
  • 0 in reply to smit majithia
    Guru 117855 points

    smit majithia said:
    please explain what exactly I2CMasterErr will do

     

    I2CMasterErr is not listed w/in your flow-chart.   Perhaps it is an I2C function - included w/in vendor's (solid) API?   Search there - and/or your clarification - would better enable an (informed) response.    (such is normally required for any such "EXACT" forum response - as you dictate)   BTW - who defines, "exact?"

  • 0 in reply to smit majithia
    TI__Guru**** 244450 points
    Hello Smit

    You just answered it. The I2CMasterErr logs three error bits and this is what you need to co-relate with the application note (on the conditions when it happens) and investigate when it would happen.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 160 points

    I just happened across this thread in desperate search of what to do in the case of an ARBLST during a master transmit.

    This "Error Service" is also drawn here in the flowchart.  Does anyone know what is required to get the ARBLST bit to clear so that a retry is possible?  Apparently merely writing 0x04 to I2CMCS does not clear the condition (and it's not clear to me why one would do that anyway since we don't want to generate a STOP on the bus).

    It has been suggested elsewhere to reset the peripheral. HOWEVER what if we lost arbitration because some one is sending to us (because we also implement slave mode)?

    Is it not possible to build a (reliable) multi-master i2c bus with this peripheral?

    Please, help!

  • 0 in reply to Jeff Senn
    TI__Guru**** 244450 points
    Hello Jeff,

    ARBLST status is cleared by read of the MCS register.
  • 0 in reply to Amit Ashara
    Prodigy 160 points
    That is not consistent with my experience. And seems like it would be pretty broken if true. That is: the first read of MCS would clear the bit? Leaving no one else able to detect the condition? (What if the compiler generated code that read the register twice?) My own code reads MCS hundreds of times while the incoming slave message (that caused the ARBLST) is processed and ARBLST is "stuck" at 1 and continues to be.

    Now, I suspect that it is cleared by the next write to the MCS from the peripheral itself - so that it could be cleared by generating another master write request... I have some evidence that might be true (and am trying that now), but it would be nice to get a definitive answer.
  • 0 in reply to Jeff Senn
    TI__Guru**** 244450 points
    Hello Jeff,

    I checked the design of the I2C controller and in master mode you are correct. It should clear when the next successful transmission is started.