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.

MSP430FR5739: I2C Communication Fail MSP430FR5739

Part Number: MSP430FR5739

Hello,

We are using MSP430FR5739 in our system. MSP430FR5739's job is to receive and send data by communicating with another card in the system via I2C. In this communication, MSP430FR5739 works as an I2C Slave. After an indefinite period of time, communication is disconnected and does not come back. That is, I2C interrupt cannot be received by MSP430FR5739. We are faced with an uncertain situation. We thought that clock stretching issue was happening here. Therefore, we tried to catch this situation in MSP430FR5739 through interrupt (UCCLTOIFG) by taking advantage of the 'Clock Low Timeout' issue. But there was no triggering. Does the master side need to control this situation? Our priority is to find out why this fail occurs. What could be causing this situation? We temporarily solved this problem as follows. When no data is received by MSP430FR5739 for a certain period of time (no I2C interrupt occurs), we disable/enable the I2C Bus of MSP430FR5739. The relevant piece of code that does this job is as follows. After applying this, I2C communication came back, so we could receive interrupts again. But this is not a good solution. Your ideas on this subject will be very valuable to us. Thank you in advance.

// Added to disable/enable the I2C Bus
EUSCI_B_I2C_disable(EUSCI_B0_BASE);
EUSCI_B_I2C_clearInterrupt(EUSCI_B0_BASE, EUSCI_B_I2C_RECEIVE_INTERRUPT0 + EUSCI_B_I2C_TRANSMIT_INTERRUPT0 + EUSCI_B_I2C_START_INTERRUPT + EUSCI_B_I2C_STOP_INTERRUPT);
EUSCI_B_I2C_disableInterrupt(EUSCI_B0_BASE, EUSCI_B_I2C_RECEIVE_INTERRUPT0 + EUSCI_B_I2C_TRANSMIT_INTERRUPT0 + EUSCI_B_I2C_START_INTERRUPT + EUSCI_B_I2C_STOP_INTERRUPT);

for (i = 0; i < 200; i++) // Wait 200ms
{
    __delay_cycles(8000); // Wait 1ms, ~1ms because MCLK = 8MHz
}

EUSCI_B_I2C_enable(EUSCI_B0_BASE);
EUSCI_B_I2C_clearInterrupt(EUSCI_B0_BASE, EUSCI_B_I2C_RECEIVE_INTERRUPT0 + EUSCI_B_I2C_TRANSMIT_INTERRUPT0 + EUSCI_B_I2C_START_INTERRUPT + EUSCI_B_I2C_STOP_INTERRUPT);
EUSCI_B_I2C_enableInterrupt(EUSCI_B0_BASE, EUSCI_B_I2C_RECEIVE_INTERRUPT0 + EUSCI_B_I2C_TRANSMIT_INTERRUPT0 + EUSCI_B_I2C_START_INTERRUPT + EUSCI_B_I2C_STOP_INTERRUPT);

  • Hi,

    This issue sounds interesting to me. The I2C receive interrupt can not be triggered after an indefinite period of time with no data transaction. And this issue can be solved by reinitialize the I2C module. 

    Some thoughts on my side is that there is some noise on the I2C bus, and the MCU consider the noise as a valid clock and enters into receive status. And when the actual data comes, the ACK bit is out of sync compare to the host. And that causes communication error. 

    Check if there is noise on the I2C line first. And check if it can solve the issue. 

    Best regards,

    Cash Hao

  • In fact, the communicating card in the system is constantly sending data (20 data per second) to the MSP430FR5739 via I2C at a speed of 20Hz. Since the working scenario of MSP is based entirely on receiving this data, it stops working after a while. Because this I2C communication fail that I mentioned before is happening.

  • Hi,

    Okay. I just checked the errata of the FR5739. For the description of USCI37, reading RXBUF during an active I2C communication might result in unintended bus stalls. Your scenario is constantly receiving data. So, it is possible that you could run into this issue. 

    https://www.ti.com/lit/er/slaz392ah/slaz392ah.pdf

    Best regards,

    Cash Hao

**Attention** This is a public forum