MSP430 I2C slave - shared interrupt vector

Raymond Dunn said:

The USCI_B0 I2C subsystem uses the same interrupt vector USCIAB0RX_VECTOR for both the RX data and bus-status change. 

No. In I2C mode, RX vector handles the status change and TX vector handles both, RX and TX. However, the IFG bits keep their meaning:

"There are two interrupt vectors for the USCI module in I2C mode. One interrupt vector is associated with the transmit and receive interrupt flags. The other interrupt vector is associated with the four state change interrupt flags. Each interrupt flag has its own interrupt enable bit."

Sadly, this text doesn't tell which is which.

Raymond Dunn said:

when processing the bus-status change, is there any flag that needs to be acknowledged to satisfy the interrupt?

As with all other interrupts except for the ADC10 and Timer-CCR0 interrupt, you'll have to clear teh IFG bit that caused the interrupt, either manually, or by readign the IV register (if available) or removing the interrupt cause (e.g. writing to TXBUF, reading RXBUF). Some may auto-reset. Like UCNACKIFG and UCSTPIFG are cleared by an incoming start condition etc. But if you're already inside the ISR, you might be confused. On 5x family, there is only one interrutp vector for all USCI events, and it has an IV register, that tells you which interrupt is pending and at the same time clears the IFG bit. However, in case of I2C, its use is not recommended, since clearing the RXIFG bit also releases the I2C state machine and you might experience an immediate RX overflow :( So unless you know that you stil have enough time to read RXBUF (1 I2C clock cycle) after reading the IV register...

Raymond Dunn said:

is is possible for data RX and bus state change to occur simultaneously?

No. RXIFG happens at the raising edge of the 8th data bit when receiving. NACKIFG can only happen if you're sending, ACALIFG will happen during a start sequence and start/stop conditions can only happen while the clock is high. However, start/stop may happen shortly after RXIFG while you are still inside the ISR.
Since the USCI doesn't wait for you to handle the RX event and manually ACK or NACK, the moment you handle the RX may be when the master has already received the ACK and decides to end conversation.

Raymond Dunn said:

should USCIAB0RX_VECTOR interrupt processing check for RX or bus-status change first (one has priority over the other)

Sicne they are in two different ISRs... However, it might be a good idea that in receiving a stop condition or (re)start condition interrupt, you should check for any leftover data in the RXBUF that might just have arrived. (I don't know off-hand which interrupt has priority on 2x devices) before you do anything that might drop it.