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.

CCS/TM4C129ENCPDT: from MSP430 to TM4C - misses I2C data

Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: MSP430FR2522

Tool/software: Code Composer Studio

Hi,

We are developing a product in which TM4C129ENCPDT (I2C master) communicates with multiple MSP430FR2522IPW16 (I2C slaves) . 

I've taken the i2c example codes given for i2c for MSP430 and modified them to working as polling method.

For checking purpose and understanding the I2C master slave concept, I've connected TM4C and one MSP430 ICs and from TM4C I request continuous data and from MSP430 I repond to the request starting from 1, 2 , 3 .... 255.

TM4C code (I2C Master):

while(1)
{
UARTprintf("Data from Slave 1 (0x0A):\n");
UARTFlushTx(false);

I2CMasterSlaveAddrSet(I2C1_BASE, 0x0A, true);
SysCtlDelay(40000*10);

for(i=0;i<5;i++)
{
I2CMasterControl(I2C1_BASE, I2C_MASTER_CMD_SINGLE_RECEIVE);

//wait for MCU to finish transaction
//while(I2CMasterBusy(I2C1_BASE));

SysCtlDelay(40000);
//while (!(I2CMasterBusy(I2C1_BASE))); //Wait till end of transaction
while (I2CMasterBusy(I2C1_BASE)); //Wait till end of transaction
SysCtlDelay(40000);

//return data pulled from the specified register
rx_data = I2CMasterDataGet(I2C1_BASE);

UARTprintf("rx_data=%d\n",rx_data);
UARTFlushTx(false);

}

}

MSP430 code (I2C slave):

// Configure USCI_B0 for I2C mode
UCB0CTLW0 = UCSWRST; // Software reset enabled
UCB0CTLW0 |= UCMODE_3 | UCSYNC; // I2C mode, sync mode
UCB0I2COA0 = 0x0A | UCOAEN; // own address is 0x48 + enable
UCB0CTLW0 &= ~UCSWRST; // clear reset register

unsigned char i=0;

volatile unsigned char TXData = 1;
while(1)
{
if(UCB0IFG & UCTXIFG0)
{
UCB0IFG &= ~UCTXIFG0; // Clear Tx condition int flag
UCB0TXBUF = TXData++;
P2OUT |= BIT2; __delay_cycles(100000); P2OUT ^= BIT2; __delay_cycles(100000);  // some led indication that data request has come
}
P1OUT ^= BIT0; __delay_cycles(100000);// some led indication that code is still running in the infinite while
}
}

While reading from TM4C side, I'm missing some data as shown in the picture.

Thank You for your time!

  • Hi,

      Can you try to add the below two lines after you call the I2CMasterControl() like below?

    I2CMasterControl(I2C1_BASE, I2C_MASTER_CMD_SINGLE_RECEIVE);

    while (!(I2CMasterBusy(I2C1_BASE))); //Add this first

    while (I2CMasterBusy(I2C1_BASE)); //Add this second

  • Thank you for your quick reply.

    I tried it. But it didn't work.

    I guess the problem is with the msp430 side.

    Coz. I checked with a DSO and the timing diagram matches the data I'm getting.

    Is there any chance that msp430 TX buffer gets updated before the previous data stored in it gets transmitted? And this happens in a exact regular timing interval that it looks like TIVA misses data.

    Thank you for your time.

  • Hi,

      Let's make sure the problem is indeed on the MSP430 side. Can you show the logic analyzer or scope capture where you see the problem. The reason I'm asking is that I can only help on the Tiva side as this forum's expertise is mainly on the TM4C MCU. If the problem is on the MSP430 side then I will need you to open a new thread in the MSP forum group or I can move this post over there. 

  • Thank You Charles.

    I'll upload the DSO capture shortly.

    The reason why I doubted MSP430 is that, I'm blinking an LED connected to the gpio P2.2 of MSP430, whenever I get an incoming data request from TM4C MCU. (refer below line for the blinking part)

    P2OUT |= BIT2; __delay_cycles(100000); P2OUT ^= BIT2; __delay_cycles(100000);  // some led indication that data request has come

     

    And in the TM4C side, I'm requesting data in sets of five bytes i.e I request five bytes of data and I take 2 seconds delay and once again five bytes of data and then 2 seconds delay. 

    And if everything works fine, the LED should blink 5 times for every 2 seconds. But it is blinking 6 times. 

    The LED blinking at the 6th time ensures that even though I'm requesting only 5 bytes of data from TM4C, the 'if condition at' MSP430 gets true for one extra time and that is where no actual data transfer is happening but the Tx data memory gets incremented by 1.

    The if condition I used to check for incoming request in MSP430 is,

    if(UCB0IFG & UCTXIFG0) 

    Hope if the above condition is corrected, the problem will be solved.

    And it would be highly helpful if you move this post over the MSP430 forum, with all the above conversation threads. 

    Thank You for your time and support!

     

     

  • Ok, I will transfer your post to the MSP430 for further guidance. 

  • Hi, 

    What is the I2C speed setting in TM4C? And what is the pull-up resistor for I2C signals? Is it possible to slow down the I2C speed and try again? 

    Thanks, 

    Lixin

  • You can try to debug the MSP430FR2522 to check if there is the I2C data is sent out when TXData=6. If yes, you can check if TM4C has received it or not. 

    It is also recommended to use scope to probe on I2C signals to check if the TXData=6 is on sent from MSP430 or not. 

    Thanks, 

    Lixin 

  • Hi,

    Sorry, I couldn't update you. 

    The issue got resolved. In the MSP430 code, instead of checking just UCTXIFG0 flag for the data request from TM4C side, I've checked both UCTXIFG0 and UCSTTIFG flags. Found this by trial and error method.

    Don't know if it is correct or not. But worked for my requirement. 

    int count =0;
    char c;
    while(1)
    {
     // UCB0TXBUF = 'Z';
     if( (UCB0IFG & UCTXIFG0) && (UCB0IFG & UCSTTIFG))
     { 
     UCB0TXBUF = chip_data[count++];
     UCB0IFG &= ~UCSTTIFG; // Clear Start condition int flag
     UCB0IFG &= ~UCTXIFG0; // Clear Tx condition int flag
     // UCB0TXBUF = TXData0[count++];
     __delay_cycles(10000);
     if(count == size) { break;}
     //D5_ON __delay_cycles(150000); D5_OFF __delay_cycles(150000);
     }
    }

    Thank You for your time and support.