• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 491 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

F28M36P63C2: Handling I2C NACK correctly

Derek Bailey
Prodigy 240 points
Part Number: F28M36P63C2

The nice wiki on I2C http://processors.wiki.ti.com/index.php/I2C_Tips has two ways to handle a NACK while transmitting.

First in the 'Repeat Start' section, it suggests setting the CMD register to 0 to release the SCL.

if ( *I2C_ICSTR & ICSTR_NACK )
{
    *I2C_ICMDR = 0;        // reset I2C so SCL isn't held low
    return RRET__FAIL;
}


But in the 'Detecting and handling NACK' it has the following, where it issues a STOP command and then clears the NACK from the status register:

// If a NACK occurred, SCL is held low and STP bit cleared
if ( *I2C_STR & ICSTR_NACK )
{
    *I2C_MDR |= ICMDR_STP;    // send STP to end transfer
    *I2C_STR = ICSTR_NACK;    // clear NACK bit
    return I2C_FAIL;
}

What is the appropriate response? Clarifying the wiki would be appreciated.

  • 0
    Guru 30330 points
    Derek,

    I agree with you here. It looks like there is some inconsistency in the wiki page.

    Check out this thread: e2e.ti.com/.../275669 . I think that manually clearing the NACK bit Guarantees the behavior. I will seek some more clarification and update the wiki if we can.

    Thanks,
    Mark
  • 0
    TI__Guru 53115 points
    Hello,

    I'm not sure why the difference either. I can't see why one would be better for a repeat start scenario than the other. The I2CMDR = 0 approach will clear I2CMDR.ISR which will clear all of I2CSTR (not just the NACK bit), and both approaches make sure to make sure SCL isn't being held low.

    So I don't think either one is wrong. The first is maybe a little more thorough, but the second approach seems to me like it would still be sufficient if you didn't want to clear all of I2CSTR and I2CMDR for some reason.

    Whitney