Part Number: EK-TM4C1294XL
Original question: https://e2e.ti.com/support/microcontrollers/other/f/908/t/852472
Last thread ended with possibility Baudrate clock divisor fraction (BRDF) lost remainder might cause Receiver holding register to intermittently fail to detect next start bit (after byte 15) is read from FIFO when TMIC bit is not auto cleared. Again the TMIC bit can not be auto cleared when receiver is not empty relative to byte 15 where it often aborts to OE (overrun) and there is no pause in the senders data stream. Yet receiver FIFO appears to fall behind senders transmission leading to FALSE positive, e.g. OE condition being incorrectly flagged for HW under run (UE) handing of serial data.
UART2 was changed to UART3 and same intermittent UE condition occurs. It would seem this issue is an UE anomaly incorrectly perceived by HW as OE error. Review of UARTprintf() code reveals a char by char Blocked read into unsigned char BUFFER, insanely checks the EMPTY flag each RX character TWICE not once. Relying on UARTprintf() as being a test of HW functionality would lead to misdiagnoses of UART issues and configuration via Tivaware thus masking over underlying issues.
Our code differs reading receiver UARTDR in circular burst of 16 data + 6 command bytes, 24 bytes total at most. This 24 byte burst read of FIFO reveals odd silicon issues perhaps in UART_FR_RXFE flag and TMIC interrupt auto bit clearing being out of sequence with SW back to back (B2B) reads of UARTDR register. As a result SW must force clear TMIC or FIFO receiver HALTS, locks up. That is abnormal behavior for NO logical reason datasheet describes or reveals. Where is the flowchart indicating how these 2 flags are to be posting results, or not in this case? Why are there no UART errata notes and post obviously would be more of a HW configuration related issue then?
The Baudrate 115200 BPS is very slow comparatively to UART capability 15MBPS, HSE bit cleared x16 divisor configures UART for low speed mode < 7.5MBPS. Might that divisor be where intermittent OE originates and what can be done to RX handler other than BUFFER the B2B reads of UARTDR? Is there a WA that can fix the sequence of TMIC relative to RXFE empty detection? has anyone ever reported in this forum such issues as being described?
uint32_t ui32RxErrorStatus; /* Load the RX error status bits */ ui32RxErrorStatus = (UART_RXERROR_FRAMING | UART_RXERROR_PARITY |UART_RXERROR_BREAK | UART_RXERROR_OVERRUN);
