[En-Nut-Discussion] Possible BUG in ARM usart driver or crt routines

[Coleman Brumley]

> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Friday, September 04, 2009 5:11 AM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] Possible BUG in ARM usart driver or
> crt routines
> 
> Coleman Brumley wrote:
> 
> > There are some issues with the AT91 USART error handling in that he
> error
> > flag doesn't get cleared correctly.
> >
> > I documented this, and a potential fix some time ago at
> > http://coleman.jandasoft.biz/?p=8
> 
> Many thanks, Coleman.
> 
> Indeed the flags never get cleared, neither in the hardware register
> nor
> in the global shadow variable.
> 
> As the AT91 channel status register keeps the errors until explicitly
> cleared by RSTSTA, we may be able to remove the register read from the
> interrupt routine to decrease the system's interrupt latency. We simply
> need to keep track of the ring buffer overflow.
> 
> My first attempt was to remove the shadow variable and skip reading the
> character from the receiver holding register, if the ring buffer is
> full. The next incoming character would automatically set the OVRE flag
> in the channel status register. Unfortunately this conflicts with
> XON/XOFF handshake. Thus, we still need the global variable to flag
> buffer overruns. :-(

In my investigation of this, I noticed that it seems that the OVRE flag in
the channel status register is always set, especially when dealing with a
lot of RS485 traffic at higher (38.4 and 76.8) baudrates.  

For what it's worth, the Linux AT91 serial driver ignores the channel status
register entirely by reading it and clearing it by RSTSTA.  So, the channel
status register is never propagated to the "upper layers".   

Coleman