Searching \ for '[PIC] PIC18 UART stops receiving' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC18 UART stops receiving'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC18 UART stops receiving'
2007\03\22@075717 by David

flavicon
face
I have a UART set up on a PIC18F2520 to use the interrupt for receiving
incoming bytes from a data radio modem.

Most of the time the UART receives bytes very reliably and then every
now and then it stops receiving.

The RCIE interrupt is still enabled, the Global interrupt is still
enabled andthe RCIF flag has not been set.

Sometimes I do notice the OERR has been set. I suspect that when there
is a lot of noise coming from the data radio that occasionally an
overrun error is occurring and this is stopping reception of further bytes.

At present my interrupt reads RCREG and THEN checks for OERR and FERR.
ie...


rx_char = RCREG
if((OERR)||(FERR))
{
 rx_char = RCREG;
 CREN = false;
 CREN = true;
}

else .....

Is this correct ?

Or should I do something like this instead ?

if(OERR)
{
 CREN = false;
 CREN = true;
}

else if(FERR)
{
 rx_char = RXREG;
}
else
{
 rx_char = RCREG;
 process.....
}

It seems from the Microchip datsheet that maybe the second approach is
the correct way to handle the com errors ?

Finally, do you ever place a check in your main code loop ?
ie. if(OERR) ..
Or is this unneccesary as the OERR and FERR will always be able to be
handled in the inerrupt routine ?

In summary, I need to now the right way to handle com errors when using
receive interrupts so that the UART cannot get into a state where it
does not receive when RCIE is set and RCIF has been cleared.

Thanks in advance for your assitance

Regards

David

2007\03\22@081413 by Alan B. Pearce

face picon face
>In summary, I need to now the right way to handle com errors
>when using receive interrupts so that the UART cannot get into
>a state where it does not receive when RCIE is set and RCIF
>has been cleared.

You have to reset the UART after an error. This sis explicitly mentioned in
the datasheet IIRC.

2007\03\22@083103 by Nigel Duckworth

picon face
I had a similar problem with an 18F452 and this code cured the problem;

if(OERR)
   {
     do{
           temp = RCREG;
           temp = RCREG;
           temp = RCREG;
           CREN = 0;
           CREN = 1;
         }while(OERR);
   }

if(FERR)
 {
   temp = RCREG;
   TXEN = 0;
   TXEN = 1;
 }        

I tested for these two errors before initiating comms (18F452 was Master).

Can't remember where I got this from or whether I worked it out from the
PIC datasheet.

Regards,

Nigel





David wrote:
{Quote hidden}

2007\03\22@092540 by M. Adam Davis

face picon face
As noted, over run and framing errors have to be explicitly cleared in
software.  They _should_ trigger the interrupt, but you might
occasionally check for those error flags in your main loop
occasionally as an extra protection.

Check the data sheet for the recommended way to clear these errors.

-Adam

On 3/22/07, David <spam_OUTdhuismanTakeThisOuTspambigpond.net.au> wrote:
{Quote hidden}

> -

2007\03\22@172846 by David

flavicon
face
This is my current code that does NOT work, every now and then the UART
stops receiving data.


  rx_char = RCREG;

  if((OERR)||(FERR))
  {
    rx_char = RCREG;
    TXEN = false;
    TXEN = true;
    CREN = false;
    CREN = true;  
    COM1.State = IDLE;
  }
  else GetComByte(rx_char);  




Alan B. Pearce wrote:
>> In summary, I need to now the right way to handle com errors
>> when using receive interrupts so that the UART cannot get into
>> a state where it does not receive when RCIE is set and RCIF
>> has been cleared.
>>    
>
> You have to reset the UART after an error. This sis explicitly mentioned in
> the datasheet IIRC.
>
>  

2007\03\22@175908 by Gerhard Fiedler

picon face
David wrote:

> This is my current code that does NOT work, every now and then the UART
> stops receiving data.
>
>    rx_char = RCREG;
>
>    if((OERR)||(FERR))
>    {
>      rx_char = RCREG;
>      TXEN = false;
>      TXEN = true;
>      CREN = false;
>      CREN = true;  
>      COM1.State = IDLE;
>    }
>    else GetComByte(rx_char);  

In addition to what the others said, I read the RCREG after I read the
status. If you read the RCREG before you read the status, there's a slight
chance that you read the error of the next byte -- which may have been put
into RCREG/RCSTA after you read RCREG, since it's the reading of RCREG that
tells the rx state machine that both registers are free now. (Check the
timing diagram of async rx in the data sheet, it usually shows this
clearly.)

Gerhard

2007\03\22@182131 by Nigel Duckworth

picon face
David, I searched the Microchip website using 'oerr' and came up with this;

http://support2.microchip.com/KBSearch/KB_StdProb.aspx?ID=SQ6UJ9A001VPG

From memory (no pun intended) RCREG is a FIFO so you might want to read
it several times to ensure it's clear
(as per my previous posted code).

Regards,

Nigel


David wrote:
{Quote hidden}

2007\03\22@202958 by David

flavicon
face
Thanks

Nigel Duckworth wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...