Hi All When the UART sets the overrun pending flag and character are still coming in as fast as the baud rate allows is there anyway to clear the condition without resetting the UART? I ask because I’m finding that when the overrun condition happens (caused by the RXBC flag never getting set when characters are coming in as fast of possible with a buffer gap timer on…) I cannot clear the FIFO by acknowledging the overrun pending flag and clearing the FIFO by reading from it using the following sequence… 1) Writing 1 to OVERRUN flag in UART Status register A 2) Writing 1 to RXBC if set 3) Reading from UART FIFO if RXRDY is set 4) looping back to step 2 if RXBC and RXRDY not both 0 The aim is not to interrupt the TX side as this may be part way through a transmission so I can’t just disable the UART and re-enable it… Anyone got any suggestions on either a way to clear the overrun or better still a way to force a receive buffer closed on a regular basis when the UART is receiving back-to-back characters continually? Thanks, Dave PS I’m seriously thinking about ditching these really bad on-board UARTs altogether and using a pair of memory mapped UARTs… something like a ST16C2550… that route has got to be a lot simpler 
Please try to use the following formular to determine the buffer gap timer. BT=(321.10Fxtal/(Bit-Rate*512))-1 Or you can try smaller values than 32 in the above formular to get the best result.
Well it appears it worse than I thought… The code doesn’t just go into an unrecoverable overrun condition, it instead hangs the core totally… and in such a way that the only way to get the board running again is to power reset… a standard reset on the reset line has no effect!!! BTW why I thought it was an overrun is that I was using LEDs to indicate which UART interrupt condition had been reached… The LED I’d chosen for the overrun interrupt just so happens comes up in a ON state if the core resets… so I think the core partially resets and then hangs… This is 100% repeatable using character match or buffer gap timer to detect a single character being received when character are coming in back-to-back…
Where does the mystical 32 come from when I want to see a single character received? Assuming 11 bits per character doesn’t the timeout need to be Timeout = (number of chars * 11 / bitrate) seconds? BT would then need to be BT = (11 * FXTAL / (bitrate * 512)) - 1) to see the 1 character that started the timer plus possibly a second back-to-back character? and less than this to see only the first char? Using either formula @9600 the value of BT is small for a single character needed to be seen… and if this timer works as detailed in the data sheet wouldn’t BT = 1 always give me RXBC for one char (the one that starts the timer)? In practice, however, I see no RXBC flag @9600 baud (FXTAL = 18432000 / 5) using BT = 1 or 7 or 22 if the UART is seeing continual ESC chars on the RX line. As the RXBC condition never gets set this eventually results in an overrun condition (end of game as this appears not to be clearable while the ESC chars are still being sent!)… Note that if the received chars are well interspersed then a RXBC condition does happen with BT = 22 (not tried the other two values)… Does the buffer gap timer work when characters are continually being received? In other words does the timeout missed if the UART is part way through receiving a char when the count gets to 0? Regards, Dave