• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 396 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.

I2C issues.

Lord Loh.
Prodigy 160 points


I am using the beagleboard platform running the 

I am having some problems with using the I2C. Each time I write a value to the I2C_CNT register and attempt yo read it, I read a different value from what I had just written to it. I tried to write with the I2C module enabled and with the I2C disabled, but it did not make any difference. Reads from the I2C_DATA returns 0xFF and the I2C_STAT register is 0x0000.

What could be the problem? I have tried all combination of reading and writing that I thought logical. Have I missed something?
Thank you.

  • 0
    Prodigy 160 points

    Adding details to the above post:

    I discovered that If I attempt yo write I2C_CNT register with a number <3, I2C_CNT remains 2. If I attempt to write I2C_CNT with a value>=3, it takes that value. I did not find this in any documentation. TI's xloader source from gitorious (the i2c functions) writes a value of 0 to the I2C_CNT although the datasheet clearly states that this is an illegal value. Any comments? Did I get anything wrong here?

  • 0 in reply to Lord Loh.
    Prodigy 160 points

    After working a bit more on the issue, I have one question that I could not find addressed in the datasheet. Does reading the I2C_CNT register return a valid value?

     

    Thank you.

  • 0
    Prodigy 160 points

    I did a bit more work on this and did not succeed :-(

    So I finally copied the i2c functions from the xloader source and things worked as it should have. Now I am trying to swap parts of the xloader code with my own and see where I had gone wrong. xloader has a piece of code in the i2c_read_byte() function
    if (status & 1<<I2C_STAT_XRDY) {
    /* Important: have to use byte access */
    val8(I2C_DATA) = regoffset;
    udelay (20000);
    if (val (I2C_STAT) & 1<<I2C_STAT_NACK) {
    i2c_error = 1;
    }
    } else {
    i2c_error = 1;
    }
    val8() is a macro I had written in place of in and out.
    My question here is - Is there a way around udelay(20000)? Can I poll a bit instead of waiting for 20ms? I really want to avoid all kinds of random delays.
    Thank you. :-)

  • 0 in reply to Lord Loh.
    TI__Expert 8180 points

    Hi,

    As far as delay is concerned, I think it should be possible to convert into poll. You may want to add poll for multiple bits from I2C_STAT register, probably ARDY and NACK.

    Thanks,

    Vaibhav

  • 0 in reply to Vaibhav Hiremath
    Prodigy 160 points

    Hi,

    Thanks for the reply. I have been putting several print statements throughout the code and have noticed that the ARDY was never set. My buffer sizes are 0 and the i2c module considers TX/RX BUFSIZE + 1. I am only doing a byte transfer at a time. So I do not think I am fulfilling the conditions for the ARDY to be set.

    As for the NACK, if a transfer is successful, NACK==0. If I poll the NACK, what value should I expect while the i2c data transfer is in progress. Is it safe to poll the BB Flag? Can I poll the NACK flag after the BB clears itself?

    Thank you.

    Bharath.

  • 0 in reply to Lord Loh.
    Prodigy 160 points

    Sorry about the previous post. I made a few mistakes :-(

    I had the XTHRESH & RTHRESH set at 0 and that would influence when the RDR & XDR flags were set and had nothing to do with the ARDY. The ARDY bit was indeeding being set as it should have. I was just reading the wrong bits.

    @Vaibhav: Thanks for the suggestion. It helped me look into things that I was overlooking.