What can cause an overrun error when DMA is used for handling RX data?

From the users guide:

“UCRXERR   Receive error flag. This bit indicates a character was received with error(s). When UCRXERR = 1, on or more error flags, UCFE, UCPE, or UCOE is also set. UCRXERR is cleared when UCAxRXBUF is read.”

 Probably, you get two errors:

First, a byte with an error is received. Likely a framing error. Caused by a slight baudrate mismatch. Or a parity error.
However, since UCRXEIE is clear by default,. This byte won’t set UCRXIFG, and therefore no DMA transfer reads RXBUF. When the next byte received, you didn’t read the previous one and you’ll get an overrun error.

However, if you set UCRXEIE, you’re not getting a notice that a byte was received with an error, you’ll simply get it as if it were received correctly.

Hi Jens-Michael,

Thank you for your reply. As usual, your explanation is quite clear.

The remaining area of unexplained behavior is the situation where
the UCOE bit is set without the UCRXERR also being set. The DMA
engine is the only 'code' that accesses UCAxRXBUF and therefore
the only code that will trigger the logic to clear the UCRXERR
and UCOE bits. Maybe some sort of timing error? I am running
the 5419A at 25Mhz.

If I enable UCRXEIE, the manual says that "Erroneous characters
received set UCRXIFG". For the USCI_Ax DMA trigger, "A transfer
is triggered when USCI_Ax receives new data".

I had originally taken that to mean that incoming data set
UCxRXIFG which in turn triggered the DMA engine. I now assume
that the DMA trigger is the reception of data, not the setting
of UCxRXIFG. This would allow UCxRXIFG to be set by the error
handling logic without triggering DMA for the erroneous byte.
Is this accurate?

I’m not sure whether the documentation can be taken literally here. I have no internal information about the internal workings of the DMA. So whether reception of data, setting IFG due to reception of data or setting IFG in general will trigger the transfer, I can’t tell. Well, at least the last one can be tested: set RXIFG in code and see whether this will trigger a DMA transfer. If so, then it is clearly TXIFG that triggers the DMA.
However, if reception itself, not setting RXIFG, triggers the transfer, you’d get more transfers, not less. But you’re looking for an overflow because there was no transfer of the previous byte (less transfers than bytes received). Which supports the interpretation that TXIFG triggers the transfer (or maybe the fact that the hardware logic sets TXIFG)

I've been intended to complete the conversation and post my results; your question provided the impetus.

I looked at 3 or 4 of our boards and noticed the MCLK, when set to 25MHZ (the max for the F5419A), had a wide variation between the boards. By dropping the internal clock rate to ~23.59 Mhz, the clock stability improved noticably and the overrun error with DMA stopped. I've not seen the overrun error since reducing the clock rate.

My recommendation is to experiment by adding an external crystal oscillator to your design and see if the behavior is resolved. I've seen several posts on different forums that essentially say that the vast majority of UART issues can be resolved by improving the stability of the UART sampling clock. Also, check the errata sheet for your microcontroller.