uart buffer overrun?

[pwdixon]

I have a simple test program that reads serial characters and echoes back on the serial port.

If I send multiple character strings then everything is ok up to a point. When the number of characters is greater than a certain point the program then only ever echoes the last character it correctly accepted even if I send a completely different character, even at a slow rate.

Code: Select all

           if(uart2_Data_Ready()){
               //get character
               ASCII_char=uart2_Read_Char();
               
               //echo data
               uart2_write_char(ASCII_char);
               
               //display recieved characters
               WriteChar(10,10,ASCII_char,0xff,0x00);
            }

WriteChar is my own function that sends the character to an SPI display.



example data sequence data:

13/10/2009 16:37:37.29 [TX] - A
13/10/2009 16:37:37.29 [RX] - A
13/10/2009 16:37:38.29 [TX] - A
13/10/2009 16:37:38.29 [RX] - A
13/10/2009 16:37:39.31 [TX] - A
13/10/2009 16:37:39.31 [RX] - A

13/10/2009 16:38:00.25 [TX] - qwer
13/10/2009 16:38:00.25 [RX] - qwer
13/10/2009 16:38:01.26 [TX] - qwer
13/10/2009 16:38:01.26 [RX] - qwer
13/10/2009 16:38:02.28 [TX] - qwer
13/10/2009 16:38:02.28 [RX] - qwer

13/10/2009 16:38:42.82 [TX] - yuiop
13/10/2009 16:38:42.85 [RX] - yuiop
13/10/2009 16:38:43.82 [TX] - yuiop
13/10/2009 16:38:43.82 [RX] - yuiop
13/10/2009 16:38:44.84 [TX] - yuiop
13/10/2009 16:38:44.84 [RX] - yuiop

13/10/2009 16:39:12.75 [TX] - 1234567890
13/10/2009 16:39:12.75 [RX] - 1234567777
13/10/2009 16:39:12.85 [TX] - 1234567890
13/10/2009 16:39:12.85 [RX] - 7777777777
13/10/2009 16:39:12.96 [TX] - 1234567890
13/10/2009 16:39:12.96 [RX] - 7777777777

13/10/2009 16:40:14.15 [TX] - qwer
13/10/2009 16:40:14.15 [RX] - 7777
13/10/2009 16:40:15.15 [TX] - qwer
13/10/2009 16:40:15.15 [RX] - 7777
13/10/2009 16:40:16.17 [TX] - qwer
13/10/2009 16:40:16.17 [RX] - 7777


from when the 7's first start to repeat whatever is sent to the system is displayed as 7 and echoed as 7.

Could this be a problem with the 4 byte buffer on the dspic33FJ256GP710 processor?

Is there a work around?

[Skyline]

Hi,
Yes, there is a buffer overrun, from the Microchip datasheet:

If the FIFO is full (four characters) and a fifth character is fully received into the UxRSR register,
the overrun error bit, OERR (UxSTA<1>), will be set. The word in UxRSR will be kept, but further
transfers to the receive FIFO are inhibited as long as the OERR bit is set. The user must clear
the OERR bit in software to allow further data to be received.

On buffer overrun the uart freezes with the last character in the receive buffer.

1. If your application can tolerate missing characters, clear the OERR bit before every Uartx_Read_Char call, this will ensure that the latest characters always get through to your application even if the application if not fast enough to handle every character.

2. If your application cannot tolerate missing characters, use the U2Rx interrupt to process incoming characters.

[pwdixon]

Thanks for the info Skyline but I couldn't find that text in my dspic33FJ256GP710 datasheet, can you point me at the datasheet you are referring to please?

[Skyline]

Hi,

The document I referred to is the dsPIC30F Family Reference Manual (DS70046E), UART section, para 19.6.2 Receiver Error Handling.

Yep, you read the 30F manual for 33F features, got myself into a bit of a fix recently re ADCs for 30F and 33F ...

I use the dsPIC33MC708, in the UART section of the device datasheet it says :

Note: This data sheet summarizes the features
of the dsPIC33FJXXXMCX06/X08/X10
family of devices. However, it is not
intended to be a comprehensive reference
source. To complement the information in
this data sheet, refer to Section 17.
“UART” (DS70188) in the “dsPIC33F
Family Reference Manual”, which is
available from the Microchip web site
(www.microchip.com).

Ok, I open up the UART section of the 33F family reference manual, it says :

Note: This data sheet summarizes the features
of this group of dsPIC33F devices. It is not
intended to be a comprehensive reference
source. To complement the information in
this data sheet, refer to the “dsPIC30F
Family Reference Manual” (DS70046).

So there! The Microchip documentation runaround. Do be careful, not all 30F sections refer to the 33F.

[pwdixon]

Thanks for the tip Skyline

[Jiellen29]

There are two basic types of UARTs: dumb UARTS and FIFO UARTS. Dumb UARTs are the 8250, 16450, early 16550, and early 16650. They are obsolete but if you understand how they work it's easy to understand how the modern ones work with FIFO UARTS ( late 16550, 16550A, and higher numbers). Note that the driver for all of them is still labeled a "8250" driver in Linux where you may see it in compile options if you compile your own kernel, etc.There is some confusion regarding 16550. Early models had a bug and worked properly only as 16450's (no FIFO). Later models with the bug fixed were named 16550A but many manufacturers did not accept the name change and continued calling it a 16550. Most all 16550's in use today are like 16550A's. Linux will report it as being a 16550A even though your hardware manual (or a label note) says it's a 16550. A similar situation exists for the 16650 (only it's worse since the manufacturer allegedly didn't admit anything was wrong). Linux will report a late 16650 as being a 16650V2. If it reports it as 16650 it is bad news and only is used as if it had a one-byte buffer.