• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 29 subscribers
  • Views 2246 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.

Unable to recover from I2C Error

Marc-Andre Harvey
Prodigy 30 points

Hi,

I am developing sample code for a BoosterPack we want to release in the next weeks. The Interface for communication is I²C. Everything works fine for both MSP430 and C2000.

However, on the Tiva C Series Launchpad, whenever there is an I²C error on the bus, The I2C_MSC_ERROR bit is set and I an unable to recover from that error ever again. I tried resetting the module by doing the following without success. Help would be greatly appreciated.

SysCtlPeripheralDisable(SYSCTL_PERIPH_I2C3);
ROM_SysCtlDelay(10000);
SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C3);
I2CMasterInitExpClk( I2C3_BASE, SysCtlClockGet(), true); //true for 400kHz i2c, false for 100kHz
ROM_SysCtlDelay(10000);

  • 0
    Guru 117855 points

    Unsure if we can meet your urgent time-frame - but you do list, "resetting the I2C module" as an objective - and then employ a somewhat circuitous/indirect approach toward that worthy goal.

    Are you aware of Stellaris function, "SysCtlPeripheralReset()?"  That function - parameterized w/"SYSCTL_PERIPH_I2C3" seems both more direct - and impactful.  (I'm unsure of the presence and/or correctness of this function - w/in rebrand schema) 

    Likely that you'll have some (perhaps all) I2C re-initialization to perform (often depends upon the degree of "horror") - visited upon your I2C connection medium and devices.

    No mention of contribution to this error by the slave(s).  Might they - in some manner - impact?

    You may aid myself/others in further diagnosis by providing some description of any/all events, devices (i.e. usual suspects) in near proximity during failure's onset.  In addition - description of the slave device(s), distance/quality of the connection medium, nearby noise sources, the incidence of this failure, results when operating @ 100KHz, and the number of board's tested - all lead to a higher quality analysis...

    As you report, "everything to work fine" via MSP & C2000 - what is the justification for yet another MCU?  (and - over what time-frame & test design/depth - do those other MCUs "work fine?")

    ,

  • 0 in reply to cb1_mobile
    Prodigy 30 points

    Well, resetting the I2C module is not so much a goal as to recover successfully from an I2C error. The implementation on the Tiva C makes it fairly easy to detect errors on the bus, but I cannot find a way to recover from them once detected.

    In my case, the error is caused by a slave device not fully compliant with the I2C standard under certain circumstances. There is no hardware fix for that.

    In any case, it does not make sense to reset the whole MCU for a communication error. SysCtlPeripheralReset(SYSCTL_PERIPH_I2C3) does indeed reset the flag and allow me to recover from the error, thank you!

  • 0 in reply to Marc-Andre Harvey
    Guru 117855 points

    Marc-Andre Harvey said:
    In any case, it does not make sense to reset the whole MCU for a communication error.

    And - in that we are in full agreement...  (and thank you for your reporting & verify)

    IMHO - those individual (and herein proven helpful) "peripheral reset" functions are "hidden/buried" w/in SysCtl section of SW-DRL-UGxxxx - far too often w/out user notice!  Would be more obvious if each was "promoted" - and granted "dual residency" - both w/in SysCtl Section and that speciic peripheral function Section - w/in SW-DRL-UGxxxx. 

    Users would have far greater chance of thus noting - if this suggestion was adopted/emplaced...  (yet far too often, "NIH" alive/well...i.e. see "endless" repetition of PF0/PD7 default "NMI" behavior - plaguing new users - and announced/alerted well over 1 year ago (including improvement/fix)  - by this reporter...yet allowed to persist...)