Best Way to Determine I2C Peripheral Transaction Is Complete

Darren Beckwith said:

I am not sure how I might miss the stop bit.  I am setting it in the interrupt and the write function is waiting on it to be being cleared.

I don't know your code, so it's difficult to say what's possibly wrong with it. I have to work on the scarce information you passed, as there is no known "I'm stuck waiting for the stop bit to be cleaed" error.
My comment about using the UCTXSTP bit to determine when a transaction ends was therefore rather generic: it isn't a good idea, no matter how and when your code does it. Unless you have a direct busy-waiting chain that sets UCTXSTP and hten waits for it to clear again.
To wait for the it to be cleared, you first have to wait for it to be set. You can miss it when during the ISR that set sit anotehr interrupt happens, whose execution takes longer than the emission of the stop condition. Depending on I2C clock speed and MCLK speed, this can easily happen. I some cases, it may even happen while you're still inside the ISR that set the bit. Then you'll never see it set (indicating that the transfer is about to be ended) and you'll never see it be cleared afterwards (obviously).

However, you said that the bit won't reset and both lines are clear. There's only one thing that comes in mind for that: the clock source that feeds the USCI is only active upon the USCIs request and deactivates before the USCI state machine updates its status. But this would be a strange racing condition (and a unusual setup anyways, especially since your main thread is active. Or you enter LPM and fail to exit it, so it only seems you're stuck in teh waiting loop while you're actually still in LPM.
Again, I don't know your code. But then, it should always fail and not only sometimes.
The device errata sheet doesn't list any known erratum regarding the UCTXSTP bit.
However, I fear that when UCTXSTP won't clear, UCBUSY won't be set too.

Ah, another possible reason comes in mind. Also a racing condition. Does it happen in transmit or receive mode?
In receive mode, UCTXSTP must be set before the ACK cycle for the currently received byte is done, or else another byte will be received before the stop. If the receiving ISR isn't prepared for this excess byte, this may cause an endless interrupt loop when this byte finally comes - and it comes before the stop condition is sent and UCTXSTP clears. This effectively puts the main code into eternal sleep. UCTXSTP will clear, but main won't be able to progress as it never gets an MCLK cycle again. So if your ISR is delayed by more than one I2C clock cycle before it sets UCTXSTP, and doesn't handle the excess byte (read it from RXBUF or clear the IFG bit or read the IV register in this case)...