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.

LP-MSP430FR2476: I2C comms hanging immediate following generation of start condition

Part Number: LP-MSP430FR2476
Other Parts Discussed in Thread: MSP430WARE, LP5569,

I am trying to establish I2C communication between an LP-MSP430FR2476 microcontroller and a TI LP5569 LED driver using the driver library provided in MSP430Ware. I am programming out of Code Composer Studio v10 .1.0.00010 and using MSP430Ware v3.80.10.09. Unfortunately, when I run the example code provided in MSP430Ware_3_80_13_03\driverlib\examples\MSP430FR2xx_4xx\eusci_b_i2c\eusci_b_i2c_ex3_masterTxMultiple.c, my program hangs on the first call to "EUSCI_B_I2C_masterSendMultiByteStart(EUSCI_B0_BASE, TXData++);". In that function call specifically, my program seems to halt in eusci_b_i2c_.c. Here's the function where my program gets stuck:

void EUSCI_B_I2C_masterSendMultiByteStart (uint16_t baseAddress,
    uint8_t txData
    )
{
    //Store current transmit interrupt enable
    uint16_t txieStatus = HWREG16(baseAddress + OFS_UCBxIE) & UCTXIE;

    //Disable transmit interrupt enable
    HWREG16(baseAddress + OFS_UCBxIE) &= ~(UCTXIE);

    //Send start condition.
    HWREG16(baseAddress + OFS_UCBxCTLW0) |= UCTR +  UCTXSTT;

    //Poll for transmit interrupt flag. <----------------- CODE GETS STUCK HERE
    while (!(HWREG16(baseAddress + OFS_UCBxIFG) & UCTXIFG)) ;

    //Send single byte data.
    HWREG16(baseAddress + OFS_UCBxTXBUF) = txData;

    //Reinstate transmit interrupt enable
    HWREG16(baseAddress + OFS_UCBxIE) |= txieStatus;
}

The only deviations I've made for the example code is to changing the slave address (I set it to 0x40 for the LP5569), the GPIO Pins (used P1, Pins 2 and 3) and I've changed the interrupt code to send certain two bytes (a control register address followed by a new value for that register, but the program never reaches that phase anyways). 

Thanks in advance!

  • I have an update with regards to this: it looks like when I unplug and replug in my LP-MSP430FR2476, I2C comms work fine. However, if I close the debugger and try debugging without unplugging/replugging the LP-MSP430FR2476, the I2C comm stop working again. It's really inconvenient to have to unplug/replug the board each time, does anyone know what might be causing this?

  • Hi Sourabh,

    Can you capture the I2C activity during this time with a logic probe or oscilloscope?

  • Hey Dennis, thank you for your response. I am getting an oscilloscope now. I don't know when I'll have it but I have to continue debugging. I've opened up a new issue with some other details that might be able to get at the root of the problem. I think part of my problem is that when the original I2C configuration code runs, it doesn't fully reset the I2C bus. As a result, the program ends up hanging between debug sessions as the interrupt fails to trigger on generation of a start condition.

    Do you know if this is a known problem with programming I2C on these boards? And if so, is there a safe way to ensure that I2C bus is clear/reset via driverlib that will ensure that interrupts will be ready to fire before starting comms with a slave?

  • Hello Sourabh,

    I was checking to see if you were able to get an oscilloscope and capture some of the I2C bus activity.

  • It's been a few days since I have heard from you so I’m assuming you were able to resolve your issue.
    If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
    If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

**Attention** This is a public forum