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.

TM4C1231H6PM: I2CMCS controller is BUSY

Part Number: TM4C1231H6PM

Hello Guys,

Greetings! 

Access to I2C appears controller is busy. What are the reasons for I2CMCS to be triggered busy?

Is there anything that could be change in the register? 

Looking forward to your response. Thank you in advance.

Best regards,

Jonathan

  • Hello Jonathan,

    The busy bit is set based on the start and stop conditions to indicate when the device is in the process of sending or receiving data. The stop condition should clear this bit.

    If the bit is stuck in busy, can you look at the I2C bus via a scope or a logic analyzer to see if the stop condition was sent?

    Are there any other bits set in the I2CMCS register?

    Is this happening mid-operation or on the first packet?

  • Hi Ralph,

    Thank you for the response. 

    Kindly confirm if the busy control based on the start and stop conditions should be the I2C bus busy and not the controller busy?

    So if this bit appears busy, check the status of the I2CMCS register before setting the bus to send data, causing other bits to be invalid, so it is impossible to send the start bit.

    It should be noted that the state of this bit is detected before the data is sent. According to the debugging results, the controller busy of the I2CMCS register changes during the detection and will always be busy.

    Finally, according to the current test situation, this phenomenon will occur without a pull-up resistor. Our customer want to know if there are other conditions that can cause this situation.

    Thanks in advance.

    Best regards,

    Jonathan

  • Hello Jonathan,

    The controller considers the bus to be BUSY between START and STOP conditions. "The bus is considered busy after a START condition and free after a STOP condition."

    So that doesn't necessarily mean the I2C bus itself is busy but that the controller did not receive a valid STOP condition after the START condition and therefore is treating the bus as busy.

    Jonathan Navor said:
    So if this bit appears busy, check the status of the I2CMCS register before setting the bus to send data, causing other bits to be invalid, so it is impossible to send the start bit.

    Correct because the controller is waiting for the stop condition.

    Jonathan Navor said:
    Finally, according to the current test situation, this phenomenon will occur without a pull-up resistor. Our customer want to know if there are other conditions that can cause this situation.

    Not having a pull-up causing behavior like this makes sense. Another situation I can think of is if the slave is clock stretching. See this explanation about clock stretching: https://www.i2c-bus.org/i2c-primer/clock-generation-stretching-arbitration/