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.

MSP430F5438A: MSP430F5438A cannot establish I2C communication with TI ADC TLA2024

Part Number: MSP430F5438A
Other Parts Discussed in Thread: TLA2024,

Hello,

 

I am debugging a board which using MSP430F5438A to control TI ADC TLA2024 to sample external input signals, now the basic I2C communication is failed to establish, I asked this question on TLA2024 thread but no answer, is there somebody of MSP430F5438A experts can help me to address this problem?

Below are the SW codes, (because just few data need transfer, do not use interruption)

  /* UCB2 initiation */

P9DIR |= 0x06;                                //P9.1 UCB2SDA, P9.2 UCB2SCL

P9OUT |=0x06;
for(i=0;i<20;i++) {}
P9OUT &=~0x06;
for(i=0;i<20;i++) {}

P9SEL |= 0x06;                            // Assign I2C pins to USCI_B2


UCB2CTL1 |= UCSWRST;
UCB2CTL0 = UCMST + UCMODE_3 + UCSYNC;                      //I2C Master, synchoronous mode
UCB2CTL1 = UCSSEL_2 + UCTR + UCSWRST;                        //SMCLK, enable SW reset

UCB2BR0 = 0x32;                                     //SMCLK/50(0x32)=80kHz
UCB2BR1 = 0; 

UCB2I2CSA = 0x48;                                 //Slave ADC(TLA2024) Addr:100 1000(ADDR = 0)

UCB2CTL1 &= ~UCSWRST; 

for(i=0;i<100;i++) {}

 

/* start to transmit data */

UCB2CTL1 |= UCTR;                           // uart in TX mode

while (IIC2_Start());

... ... omit other transmission codes

 

/* sub-function */

UINT8 IIC2_Start(void)

  {

    UCB2CTL1 |= UCTXSTT;                  // I2C start condition               -- NOTE A

    return(UCB2IFG & UCNACKIFG);                                                   -- NOTE B

 }

 

Problem phenomenon description -

UCB2CTL1 is always cannot set bit UCTXSTT=1, that means cannot trigger a START condition correctly, then cannot continue following data transmission.

 

Problem phenomenon detail -

1. Before execute trigger start condition of NOTE A, UCB2 registers value are

UCB2CTL0 = 0x0F;

UCB2CTL1 = 0x90;

UCB2IFG = 0x00;

UCB2STAT = 0x00;

2. After execute the UCB3CTL1 |= UCTXSTT to trigger a start condition of NOTE A position, these registers value change to 

UCB2CTL0 = 0x0F;

UCB2CTL1 = 0x90;

UCB2IFG = 0x022;

UCB2STAT = 0x50;

At this moment, the SCL and SDA signal wave as below picture,

Since this is the standard I2C communication sequence of MSP430F5438A, and the falling slope is pretty sharp, so just measured the rising slope of SCL and SDA signals,

Both amplitude rising time from 30% to 70% are about 780ns, less than it’s maximum 1000ns as its datasheet description.

3.And then execute the next command  return(UCB2IFG & UCNACKIFG) of NOTE B, then these registers value change to 

UCB2CTL0 = 0x0F;

UCB2CTL1 = 0x90;

UCB2IFG = 0x22;

UCB2STAT = 0x50;

Because UCNACKIFG =1 of UCB3IFG, the command while (IIC2_Start()) became a dead loop.

 

To check whether there is any problem of UCB2 configuration or any UCB2 hardware problem, I changed this I2C connection to UCB3, the UCB3 is also work well with another I2C component, the codes is almost the same, except slave address, then change the address to 0x48 as TLA2024 hardware, the results are,

1. Before execute trigger start condition of NOTE A, UCB2 registers value are

UCB3CTL0 = 0x0F;

UCB3CTL1 = 0x90;

UCB3IFG = 0x00;

UCB3STAT = 0x00;

2. After execute the UCB3CTL1 |= UCTXSTT to trigger a start condition of NOTE A position, these registers value change to 

UCB3CTL0 = 0x0F;

UCB3CTL1 = 0x92;

UCB3IFG = 0x02;

UCB3STAT = 0x50;

The SCL and SDA wave of this moment as below,

        3. And then execute the next command  return(UCB2IFG & UCNACKIFG) of NOTE B, then these registers value change to 

UCB3CTL0 = 0x0F;

UCB3CTL1 = 0x90;

UCB3IFG = 0x22;

UCB3STAT = 0x50;

 

Because UCNACKIFG =1 of UCB3IFG, the comand while (IIC2_Start()) became a dead loop.

The hardware schematic as below,

Appreciate your support in advance!

Best Regards!

QM

 

  • After setting UCTXSTT, you must wait for UCTXIFG, and then write the first byte to TXBUF.

    As shown in the waveform, the master has transmitted the slave address and the W bit, but the clock is held low before the ACK. This happens when TXBUF is still empty.

    See figure 38-12 of the User's Guide:

    You can also check for UCNACKIFG. But then you must ensure that it is cleared before you start a transaction.

    (10 kΩ is rather large for an I²C pullup; usual values are 4.7 kΩ or smaller.)

  • Hello Clemens,

    I DO appreciate you reply.

    After setting UCTXSTT, if use UCTXIFG to determine whether can write byte to TXBUF, I changed the data transmission portion codes as below,

                                /* start to transmit data */

                                UCB2CTL1 |= UCTR;                           // uart in TX mode

                                UCB2CTL1 |= UCTXSTT;  // I2C start condition  

                                 for (i=0; i<4; i++)

                                     {

                                           UCB2TXBUF = TXBuf[i];

                                           while (!(UCB2IFG & UCTXIFG))                  --NOTE C

                                                   {

                                                   }

                                     }                            

                                  ... ... omit other transmission codes

    As my previous test result, after setting UCTXSTT, UCB2IFG=0x22, that means UCTXIFG=1, then I can put the 1st byte to TXBUF, then UCTXIFG cleared, UCB2IFG=0x20; then the codes became dead loop at NOTE C position,  because UCTXIFG is always =0, that means the transmission is failed.

    So I think the problem still MSP430 did not establish I2C communication with the TLA2024, the other work well I2C component, the UCBxCTL1 will became 0x92, that means UCTXSTT bit is set, the MSP430 and TLA2024 have successfully generated a START condition, and also cleared UCNACKIFG of UCBxIFG, since this bit is automatically cleared when a START condition is received.

    I test other work well I2C communication ports signal wave, when setting UCTXSTT, the wave is

    and then when putting the 1st byte to TXBUF,

    and then stop,

    But the TLA2024 is not like this, no matter I connect TLA2024 I2C SCL and SDA lines to UCB3 or UCB2, since I have use UCB1 and UCB3 to drive other 2 I2C components successfully.

    It is really hard for me to understand why TI's I2C component (TLA2024) cannot connect TI MCU (MSP430) easily, while it is easily to connect with other company's I2C components. I have spent about 3 weeks on this, and we also met high project schedule pressure, so can you please do me a favor to check with TLA2024 support experts for how to configure the corresponding I2C registers and design software codes? or can you please find some demo codes for my reference?

    I DO APPRECIATE your stronger supports!

    BTW, for the pull up resistor value, due to we want the the hardware less power consumption as much as possible, so select 10k, and test the signal quality is met component technical requirement as these test data, by your suggestion, I am going to decrease their values.

    Thanks very much for your support again!

    Best Regards!

    QM

  • You must wait for TXIFG before writing TXBUF. (And please let it run without interruption and show the entire waveform.)

    (This has nothing to do with the TLA2024; the master stalls the bus before the slave has the opportunity to ACK, or not.)

    (If you want to reduce power consumption, consider replacing the pullups with constant-current sources, or adding an LTC1694/ISL88694/LTC4311. But that might be too expensive.)

  • Hello Clemens,

    After setting UCTXSTT by UCB2CTL1 |= UCTR, the UCB2IFG = 0x22 immediately, that means UCTXIFG and UCNACKIFG have been set to 1, is that mean UCTXIFG has arrived?

    Thanks!
  • What do you mean with "immediately"? Are you reading UCB2IFG in code, or with the debugger?

    Why are checking UXNACKIFG? This bit cannot make sense until after the first ACK is expected.

**Attention** This is a public forum