This MCU has an errata USCI42 that has no official workaround provided by TI.
Here is the errata
Reading about this errata on some other threads in this forum, I gathered that this issue really only takes effect if the USCI is asked to function in half-duplex mode (ie: RS485). For full-duplex mode (ie: SPI), this errata is not applicable and can be ignored.
I would like to propose an unofficial workaround for the half-duplex case. Please let me know if it has a possibility of working.
First of all, looking at the block diagram of the USCI module shows that, for transmission, it has two main components: the transmit buffer and the output shift register.
When transmitting a byte, the byte is first loaded into the TX buffer and then passed on through to the output shift register that actually sends the byte. There are two flags that can be observed during this process, UCTXIFG and UCTXCPTIFG (this latter flag is the one under question by the errata). The UCTXIFG is set each time that a byte has been transferred out of the tx buffer, in other words, when the tx buffer is empty. UCTXCPTIFG is set when the output shift register has transmitted all bits and there is no additional byte to be transferred from the tx buffer, in other words, both the tx buffer and output shift register are empty. My interpretation of the errata is that the UCTXCPTIFG is erroneously being set after each byte is sent, rather than at the moment that both tx buffer and shift registers are empty. This makes its function redundant as that is essentially what the UCTXIFG flag does.
My proposed alternative way is as follows:
First, find how long it takes to transmit a byte, say, 2ms. If we are transmitting 10bytes, that should takes 20ms. Under optimal conditions, after the 10th byte has been sent, UCTXCPTIFG would be sent and the controller can change to RX mode and get ready to receive. An alternative is to set a timer after the 10th bytes has been sent for say, 1ms or however long we feel is long enough to safely feel that the final byte has been sent, and then have controller change to rx mode. Of course, the alternative way is not as exact as the official way, hence why it is less optimal.