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.

I2C on LM4F120H Launch board



Hello,

my Problem with I2C on LM4F120H, Silikcon A3 in this order:

a)   I2C0 functions was 100% working...i saved this as Reference Project

b)  next step... add I2C2 functions, the should work together --> now I2C0 & I2C2 dont work.

c)  Ok, one step back: I tried the first  I2C0 reference Project from point (a) ---> dont work, i changed nothing

dont work means.....that i have no signals on the SDA/SCL pins.

Somebody know this behavior??

My first contact with the loobpack example was the same: 2times was working,--> 2days no working, i dont know why---> ans then working again without problems.

Really very tricky this module.

best regards

Walter

 

  • Have read very similar accounts - many times now.

    Suggest that - if you can restore your I2C0 functionality - that you "record" all pertinent Register Values.  (and those "higher order" registers - which may impact I2C settings or operation)  Armed w/this data - believe you'd be better able to identify what has, "run amuck" when operation ceases...

    Often - with such issues - we find that the peripheral module has "incompletely" reset - thus even though set-up/config code is, "the same" - performance is different.  This is especially apt to occur if you leave your board powered/running after (a) above, and then recode to (b) - or even to (c).   A good test of this would be a clean power down, then power up - and reset of the I2C module prior to set-up/config code.

    Also possible that "some percentage of these MCUs" suffer this - others do not.  Seems sure that the loopback worked when implemented/tested by TI - perhaps a difference in procedure - or program sequencing - or variation in "reset" time/place may be causal nexus...

    There are so many reports of "loopback" problems - one may wonder if "some" unwanted interaction occurs among the various I2C peripherals.  Our group always prefers to "talk/test" with a separate I2C device - which is "known good."   Other than "ease/convenience" - such "loopback exercise" provides no real value - thus our strong preference for basic, known-good, external, slave I2C device - as our substitute for - and total elimination - of this disheartening "loopback" issue... 

    The opportunity for, "ease/convenience" (the promise of "loopback") seems to be lost with so many suffering, "failure to connect/communicate."

  • Hi Walter,

    you didn't explain why you want to use loopback mode! Do you want to use it just for testing the I2C communication or what's the particular reason?

    I've posted a working I2C driver API (master only) here http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/473/t/235926.aspx to get others started in using I2C on the Launchpad (and/or other Stellaris devices).

    So, why not simply use this as a startig point and configure another I2C peripheral for slave mode  (If you don't have a I2C device to talk to)? If this is working you can write your own code for loopback based on your results.

    aBUGSworstnightmare

  • Hello,

    thanks for your fast answers!!!

    I am glad to have chosen TI for our new project.

    Now both I2C modules are working.

    The  errors was:

    a) Only with a Hardware reset and without JTAG the I2C is running. Why, i dont know...

    b) my fault: After adding the second I2C, the slave addresses from i2C0 & I2C2 was interchanged

    @ aBUGSworstnightmare: The PCB prototyp is in some days  ready for testing, now i have to live with the launchboard.

    best regards

    Walter