Question about I2C

Well, if it's not the slave, then it's the master. And without getting into your code, the oscillograms doesn't look right. I2C data transfer have to start with a start bit (Data line pulled low while clock line remains high) and ends with a stop bit. So it seems that your code isn't working properly.

Yes, well. I kindda have the feeling the problem is in my code. But i just copied one of the code examples so It should work wright?

I will draw the same oscilograms with one of the launchpad code examples with the I2C wire unplugged (but with the 10k pull-ups) and see what happens.

Oh, my bad, start bit looks OK, but I don't know why the master would pull the clock line low at the end.

Hello,

I have tested this with one of the Grace Examples for the MSP430: USCI I2C Master TX. The same thing happens. It gets stuck in LPM. Why is the clock being pulled down in the end of the transmission if there is no slave connected to the i2C wire?

This is my setup for this test:

//******************************************************************************
//  MSP430G2xx3 Demo - USCI_B0 I2C Master TX single bytes to MSP430 Slave
//
//  Description: This demo connects two MSP430's via the I2C bus. The master
//  transmits to the slave. This is the master code. It continuously
//  transmits 00h, 01h, ..., 0ffh and demonstrates how to implement an I2C
//  master transmitter sending a single byte using the USCI_B0 TX interrupt.
//  ACLK = n/a, MCLK = SMCLK = BRCLK = default DCO = ~1.2MHz
//
//                                /|\  /|\
//               MSP430G2xx3      10k  10k     MSP430G2xx3
//                   slave         |    |        master
//             -----------------   |    |  -----------------
//           -|XIN  P1.7/UCB0SDA|<-|---+->|P1.7/UCB0SDA  XIN|-
//            |                 |  |      |                 |
//           -|XOUT             |  |      |             XOUT|-
//            |     P1.6/UCB0SCL|<-+----->|P1.6/UCB0SCL     |
//            |                 |         |                 |
//******************************************************************************
/*
 * ======== Standard MSP430 includes ========
 */
#include <msp430.h>

/*
 * ======== Grace related declaration ========
 */
extern void CSL_init(void);

unsigned char TXData;
unsigned char TXByteCtr;

/*
 *  ======== main ========
 */
int main(void)
{
    CSL_init();

    TXData = 0x00;                            // Holds TX data

    while (1)
    {
      TXByteCtr = 1;                          // Load TX byte counter
      while (UCB0CTL1 & UCTXSTP);             // Ensure stop condition got sent
      UCB0CTL1 |= UCTR + UCTXSTT;             // I2C TX, start condition
      __bis_SR_register(CPUOFF + GIE);        // Enter LPM0 w/ interrupts
                                              // Remain in LPM0 until all data
                                              // is TX'd
      TXData++;                               // Increment data byte
    }
}

//------------------------------------------------------------------------------
// The USCIAB0TX_ISR is structured such that it can be used to transmit any
// number of bytes by pre-loading TXByteCtr with the byte count.
//------------------------------------------------------------------------------
unsigned short USCIAB0TX_ISR(void)
{
    if (TXByteCtr)                            // Check TX byte counter
    {
      UCB0TXBUF = TXData;                     // Load TX buffer
      TXByteCtr--;                            // Decrement TX byte counter
      return 0;
    }
    else
    {
      UCB0CTL1 |= UCTXSTP;                    // I2C stop condition
      IFG2 &= ~UCB0TXIFG;                     // Clear USCI_B0 TX int flag
      return CPUOFF;                          // Exit LPM0
    }
}

Without getting into or testing your code, just a guess, but maybe you should add PORT1 setup, like set clock pin to output (or input - high impedance), select it's functionality (P1SEL) etc. You should take the Familys User Guide and read the description of USCI I2C mode. I actually haven't used so without looking into user guide I can't tell you anything for sure. But take a look and if you still can't get it to work, it will try the code my self (but only in evening CET).

Hi! Thank you, once again for taking interest in my post.

I checked the guide and I think I have an explanation for this.
I think the configurations needed are correct in my code. The problem I see here, is that on the 9th clock cycle, the master expects an ACK from the slave. The ACK will trigger the interrupt and the stop condition is sent.

As we can see in the oscilograms, the ACK is not there (the SDA line should go low in the 9th clock cycle). If the ACK doesn't come, then it is a NACK. In my code I'm not testing the flags for NACKs, causing the micro to stuck in LPM.

I'm not sure about this, but if what I said is true, the conclusion is that the slave is, simply, dead or not there. This is very bad for me because I printed a PCB board for the TLC ship and this means I have some kind of problem in the hardware.

What do you think?

Cheers

Hi again,

I solved the problem!
I think what I sad before is true, but the problem was the 7Bit address. I was writing the 7bit address + the r/w bit as the address. Arrgh. Sorry about this waste of time. 

Pedro Serra said:

But the solution does not reside on the address (unfortunately).

Pedro Serra said:

#define TLC59116_ADR 0xD0 // this is the allcall address
UCB0I2CSA = TLC59116_ADR;                // Slave Address

0xD0 is not a valid slave address. Slave address is a 7 bit value and 0xd0 is obviously 8 bit, so it can't be right.
Apparently, 0xD0 is a start byte, consisting of 7 bit slave address and 1 bit R/W.

So the slave address is apparently 0x68 (right-justified 7 bit) which needs to be written to UCB0I2CSA. The USCI will padd it then with a R/W bit based on UCTR bit wehn sending the start byte.