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 operation trivia

Hi,

   I am using MSP430X21X2 as a slave device in I2C configuration. I am using it to dump multiple bytes of data over the I2C interface. However, I am facing a weird issue

When I generate a delay of around 1ms anywhere in the main loop (not in any interrupt routine), the slave does not receive / receives utmost 2 bytes of data on the I2C. It works perfectly when there is no delay but the application requires a delay of 1.5 ms. Can anyone shed some light whats going on?

  • Hello,

    the Slave may stretch the clock in I2C:

    In an I2C communication the master device determines the clock speed. Unlike RS232 the I2C bus provides an explicit clock signal which relieves master and slave from synchronizing exactly to a predefined baud rate. However, there are situations where an I2C slave is not able to co-operate with the clock speed given by the master and needs to slow down a little. This is done by a mechanism referred to as clock stretching. An I2C slave is allowed to hold down the clock if it needs to reduce the bus speed. The master on the other hand is required to read back the clock signal after releasing it to high state and wait until the line has actually gone high.

    Clock stretching should be performed automatically by USCI in I2C Receiver Slave Mode:

    If the previous data was not read from the receive buffer UCBxRXBUF at the end of a reception, the bus
    is stalled by holding SCL low. As soon as UCBxRXBUF is read, the new data is transferred into
    UCBxRXBUF, an acknowledge is sent to the master, and the next data can be received.

    One reason could be an erroneous I2C implementation on Master, that ignores the clock stretching and sends data anyway:

    The USCI module supports clock stretching and also makes use of this feature as described in the
    Operation Mode sections.
    The UCSCLLOW bit can be used to observe if another device pulls SCL low while the USCI module
    already released SCL due to the following conditions:
    • USCI is acting as master and a connected slave drives SCL low.
    • USCI is acting as master and another master drives SCL low during arbitration.
    The UCSCLLOW bit is also active if the USCI holds SCL low because it is waiting as transmitter for data
    being written into UCBxTXBUF or as receiver for the data being read from UCBxRXBUF.
    The UCSCLLOW bit might get set for a short time with each rising SCL edge because the logic observes
    the external SCL and compares it to the internally generated SCL.

    Regards Marco

**Attention** This is a public forum