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.

msp430f2132 I2C read/write of a LTC2942

Other Parts Discussed in Thread: MSP430F2132

Hej,

i have a problem with the I2C communication between a MSP430f2132 and a Fuel Gauge from LT .

To start the communication like its dokumented you have to UCTR to 0 (yellow highlighted) and send the start condition. But if i do so i'm running in a trap (green Highlighted) normally this bit (UCTXSTT) is set back when the startcondition is sent but not in this case.  Is there any workaround to fix this problem?

Thank you very much

franz

void i2c_start(){
    UCB0CTL1 |= UCTXSTT;                    // I2C start condition
    while (UCB0CTL1 & UCTXSTT);             // Loop until I2C STT is sent
}

void i2c_stop(){
    UCB0CTL1 |= UCTXSTP;		// Stop
    while (UCB0CTL1 & UCTXSTP);
}

void i2c_write(unsigned char cmd, unsigned char data){

	UCB0CTL1 &= ~UCTR;                      // I2C TX
	i2c_start();

	UCB0TXBUF = cmd;			// write register
	while(IFG2 & UCB0TXIFG);

	UCB0TXBUF = data;			// write data
	while(IFG2 & UCB0TXIFG);

	i2c_stop();
}

 

  • Are you sure that bit UCTR is also set in i2c_start?
  • yes

    on my logic port  i get this out. But the first byte shout be the address + a zero bit for writing onto the bus.

  • In transmit mode, sending the start byte stops at the ACK cycle until either something is written to TXBUF or UCTXSTP is set.
    However, I'm a bit puzzled that your function is called i2c_write, but it clears the UCTR bit (which means the USCI shall receive)
    (UCTR means UsCi TRansmit). Note that when UCTR is set, the R/W bit in the generated start byte is cleared (master sends to slave) and when UCTR is clear, the R/W bit is set (master reads form slave)
  • i tried so, but then it stucks in the while loop that waits until the the slave acknowledges. (line 3 in the code)
  • The logic capture you show above has the correct slave address. It also shows a read transaction from register 0, followed by a NAK.

    Are you trying to read from the part or write to it?

    If you are trying to write, you cannot write to register 0 on that LT part (reg 0 is read-only).
    Why wait on UCTXSTT? Just wait for the TXIFG flag and then write your register index, wait on TXIFG, write data, then wait to write UCTXSTP.

    If you are trying to read, change the name of your function for starters.
  • The capture shoult show a wirte process and i've tried to write 0x34 to 0x01 but the capture shows what came out.
    I've also tried your suggest but it didn't work
    thanks for your effort
  • Brian Boorman said:
    It also shows a read transaction from register 0

    The operation is a read operation, it shows receiving of a 0x00 data byte. No information where it comes from, no reference to 'register 0'. it just shows that a data byte of 0x00 is received because the slave decided to send it.


    Franz: yes, if you set UCTR to tell the USCI that istshall transmit something, it does not complete the start byte ACK cycle until you give it something to send, or make an instant stop. I already told you this.
    As soon as you have UCTR and UCTXSTT set, UCTXIFG is set to request something to send. If you don't give something to send or set UCTXSTP, the USCI will stall on the ACK cycle. This expected, intended and documented behavior.
    Please take a second look at the diagram in the users guide. It clearly shows you what happens when and what you have to to.
    BTW: clearing UCTR because your code hangs with UCTR set, doesn't make the transmit work, it makes the transmit being a receive. And is surely no approach to fix anything. ;)

**Attention** This is a public forum