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.

MSP430FR6043: Device Erratasheet USCI42

Part Number: MSP430FR6043


As I was going through the erratasheet for the MSP430FR6043IPN, I came across USCI42 which states the following:

USCI42 USCI Module

Category: Functional

Function: UART asserts UCTXCPTIFG after each byte in multi-byte transmission

Description: UCTXCPTIFG flag is triggered at the last stop bit of every UART byte transmission, independently of an empty buffer, when transmitting multiple byte sequences via UART. The erroneous UART behavior occurs with and without DMA transfer.

Workaround: None.

Why is there no workaround for this? Does the errata pose a problem with using UART function for RS232 communication? 

Thank you,


  • Hi John,

    There is no workaround of this errata. You could see the e2e post for the original.

  • Thanks Allen for pointing me to this post. It's unfortunate that there is no clear workaround for this.

  • Hi Allen,

    I'm still trying to figure this out. The following workaround was sent by ctm in the post you sent. Why is this not a published workaround as I don't see how you can't just monitor both UCTXCPTIFG and UCTXIFG? 

    Possible work-around is as follows:

    ( Forth Snippet )   
       DMAIFG     DMAxCTL DMA4-Base + waitflagset          \ wait for DMA to complete
       UCTXIFG    IFG eUSCI-A3-Base + waitflagset          \ wait txbuf
       UCTXCPTIFG IFG eUSCI-A3-Base + bic!                 \ clear stop bit flag   
       UCTXCPTIFG IFG eUSCI-A3-Base + waitflagset          \ wait stop bit flag 

  • Hi John,

    There is no official workaround released. As the old post said, you could set a count to calculate the number of interrupt you have received for bytes counting. Both flag will set when each byte transition is finished. So why you want to monitor both flags if you want to indicate multi byte transfer finished? 

  • Allen, 

    Are you saying that TXBUF is also triggered after each byte is transmitted? Not when the buffer is completely emptied?

    This would that the only way to skirt this issue if you are sending variable length messages is to pre-calculate the byte length of your message and use that number as your count threshold?

  • I believe that it is possible to use TXIFG to determine if the transfer is really complete. But only if you use the IV register in your ISR.

    Since the TXCPTIFG flag is set after the stop bits are sent, there should be a delay between TXIFG and TXCPTIFG. (TXIFG has higher priority as well) Reading the IV register clears the interrupt and flag (so sayeth the docs) so TXIFG will be cleared even if you don't write more data to TXBUF. That being the usual way of clearing TXIFG.

    So the TXIFG interrupt occurs, the ISR checks and finds no more data to send, clears TXIE, and exits. Now there is data in the transmit shift register and two TXCPTIFG interrupts on the way.

    The first will find TXIFG clear as usual. When the transmit shift register empties it sets TXIFG but TXIE is clear so no interrupt happens to clear it. Now the TXCPTIFG interrupt happens and finds TXIFG set.

    This of course depends on thinly documented details so might work now but fail on future hardware.

    You could also use TXIE to aid TXCPTIFG. If TXIE is set, clear a static counter. If TXIE is clear increment the counter and if it equals 2, the transfer really is complete.

  • David,

    Thank you for the explanation. It seems to me that either of these workarounds (monitoring the IV register or adding a count in the TXCPTIFG ISR) should work in every case for this piece of hardware. Is there a reason why they are not published in the Erratasheet? 

  • Probably because nothing will turn off the extra TXCPT interrupts. You just have to deal with them as is.

    I just found the bug, TI is in charge of the errata.