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.

MSP430FR59941: Nothing but issues with I2C: Part 2

Part Number: MSP430FR59941

The original thread is locked,... So I came here.  The original thread is: https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/819643/msp430fr5994-nothing-but-issues-with-i2c

Much like Ashton, I have been in TI I2C hell for many, many weeks.  The MSP430FR599x user's guide, section 32.3.4 say's: The latest code examples can be found on the MSP430 web under "Code Examples".  I have found none.  The examples given in the user's guide are rudimentary and offer no insight about how a real interrupt system would be implemented.  i.e. It is just usless.  The I2C libraries offer no insight into the operation of the code.  So don't bother.  The forums offered nothing until I stumbbled across Ashton's post.  Many thanks to Ashton for posting something usefull.  (Major turd on TI for offering nothing.)

Ashton's last post made a comment about a simple fix.  I have no idea what that may be, but I have found an issue with the STOP-ISR.  A STOP has a higher priority than an RX.  So the STOP may get serviced before the last Rx-byte gets grabbed.  To resolve this, I added a "check for last-byte" in the STOP-ISR:  (2 lines added)

case USCI_I2C_UCSTPIFG:
            if(transmit_initiated){transmit_initiated = false;}
            if(receive_initiated) {
if(*UCBXIFG & UCRXIFG) // Does RX have data?
*rxBuffer++ = UCB2RXBUF; // Get RX data
receive_initiated = false;
}
break;

Finally,.... I have a working interrupt driven I2C.  (Why was this so friggin difficult?)

**Attention** This is a public forum