Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

MSP430 - I2C, one bit shifted to the left after the first byte

Other Parts Discussed in Thread: MSP430F5438A

Hello,

I'm facing a problem using the MSP430F5438A I2C peripheral in transmiter slave mode. Receiver slave mode works perfectly.

The master issues a Read request (slave address = 0x10) and tries to read 3 bytes. At the slave (MSP430) the byte 0x0C is always reloaded whenever the interrupt with origin in UCTXIFG is activated.

I'm using 7bit addressing, no multi-master, 12k pull ups.

The results:

Address byte -> OK

First byte -> OK

Second byte -> The MSP is one clock desynchronized. Due to that, it fails to read the ACK send by the master which is issued one clock later.

Third byte -> Aborted in the MSP, the master reads it as 0xFF

Please see the picture. In this example, the clock is extremely slow to avoid any high speed issues.

Am I doing something wrong?

Thank you

  • This is really strange. The clock signal looks good, and if you received the first two bytes correctly, there is no reason why you should fail on the 3rd.
    There is apparently no delay in stuffing data into TXBUF, as there would be clock stretching visible then.
    It might be something with your code flow. You should post your code. Perhaps you're aborting the transfer prematurely.
    The double-buffering of TXBUF significantly improves throughput, but makes things less straight than one might think.
  • I realize this is an old thread, but I just hit the same problem.

    In my example of this the MSP430 is the bus master, and has two peripherals attached to it.  One of the peripherals works perfectly, and the other has the first byte of the i2c message shifted left one bit.  The chip address is fine, but the register address is shifted.

    What did you end up doing?  Was it resolved?

    Thanks!!

  • Hello,

    As far as I remember,  was right about clock stretching. In my case, the MSP430 was in slave mode and trying to stretch the CLK while loading the next octet. However, the master (an FTDI chip) did not support clock stretching and was creating this kind of problems. I think I tried to optimize the code and avoid having other interrupts which may delay the loading of the next octet to TXBUF.

    Best regards,

    Mário

  • That's very useful. I'll check it out. Thanks!

**Attention** This is a public forum