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.

TMS320F28379D: Ack polling in I2C bus

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hi, 

I am using the I2C example, i2c_ex2_eeprom provided with the C2000 software. Everything works perfectly. However, I am trying to understand how the ACK polling occurs. 

After writing a byte to the EEPROM, it takes 5 ms for the EEPROM to finish writing data. During that time the slave address output by the master is not acknowledged. So, master can do that over and over again until the slave acknowledges its address to find if the write cycle is over. This is called Ack polling in the EEPROM datasheets.

Does F28379D's I2C module do this on its own (in hardware) if we begin a read cycle immediately after writing a byte to the EEPROM?

  • Hi Dhammika,

    Are you using the driverLib example or the bit field (header files) I2C example within C2000ware?

    Dhammika Wijesundera said:
    Does F28379D's I2C module do this on its own (in hardware) if we begin a read cycle immediately after writing a byte to the EEPROM?

    Are you meaning will the F2837x continuously send the slave address until it receives an ACK on it's own? If so, then no, you will have to kick off a START condition + slave address for each attempt.

    Best,

    Kevin

  • Hi Kevin,

    I am using the driverLib example.

    When we begin the read cycle immediately after the write cycle, don't we send the start+slave address? I cannot see that being done repeatedly.  

  • Hi Kevin,

    I tested this by putting a break point at the line shown below. These lines are inside the ISR. The code never stops there and the read is successful.

    Thanks,

    Dhammika

    // Interrupt source = Register Access Ready
    //
    // This interrupt is used to determine when the EEPROM address setup
    // portion of the read data communication is complete. Since no stop bit
    // is commanded, this flag tells us when the message has been sent
    // instead of the SCD flag.
    else if(intSource == I2C_INTSRC_REG_ACCESS_RDY)
    {
        // If a NACK is received, clear the NACK bit and command a stop.
        // Otherwise, move on to the read data portion of the communication.
        if((I2C_getStatus(I2CB_BASE) & I2C_STS_NO_ACK) != 0)
        {
            I2C_sendStopCondition(I2CB_BASE);               // I set a break point here - Dhammika
            I2C_clearStatus(I2CB_BASE, I2C_STS_NO_ACK);
        }
        else if(currentMsgPtr->msgStatus == MSG_STATUS_SEND_NOSTOP_BUSY)
        {
            currentMsgPtr->msgStatus = MSG_STATUS_RESTART;
        }
    }

  • Hi Kevin,

    I am sorry, the time taken when we stop at the break point is enough for the write cycle to complete (I had a break point at the point where the read cycle begins as well). That is why the break point above did not occur.

    I can see where the Start is sent again. 

    Thanks,

    Dhammika