| View previous topic :: View next topic |
| Author |
Message |
itt
Joined: 11 Oct 2004
Posts: 2
|
| UART Receive Interrupt Stop |
 Posted: Mon Oct 11, 2004 11:27 am |
 |
|
All,
My receive interrupt stop working after running few days randomly.. Does any of you have problem like this?
Inside the receive interrupt, can getch() function not return? or Can the RCREG becomes empty due to error?
Thanks for your help.. |
|
 |
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Oct 11, 2004 11:30 am |
|
|
| Read the section in the manual on #use RS232 and the ERRORS parameter. If an error occurs and you do not handle it, reception will stop unless you have specified the ERRORS in the #use. |
|
|
itt
Joined: 11 Oct 2004
Posts: 2
|
|
| Posted: Mon Oct 11, 2004 1:41 pm |
|
|
Thanks for the advise but probably I need to ask you a little bit more.
I've handled the OVR Run Error directly from RCSTA, and reset the Receive when that happen. I do not define the ERROR in the directive #use rs232. Do you think there are still some errors that if it's not handled will stop the reception? |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Oct 11, 2004 1:53 pm |
|
|
| Post your receive routine and we can check it out. |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Oct 11, 2004 2:47 pm |
|
|
| itt wrote: | Thanks for the advise but probably I need to ask you a little bit more.
I've handled the OVR Run Error directly from RCSTA, and reset the Receive when that happen. I do not define the ERROR in the directive #use rs232. Do you think there are still some errors that if it's not handled will stop the reception? |
'Reset the receive'?. You actually have to turn the continous receive off, and then on again to clear this error. There is also the possibility of framing errors.
| Code: |
inval=RCREG;
if (OERR | FERR) {
CREN=false;
CREN=true;
}
|
With suitable defintions for the framing error, overrun error, and continuous receive enable bits, together with the receive register, this has run fine for me, for years.
It originally dated from before the 'ERRORS' option was added to this compiler.
Best Wishes |
|
|
Guest
|
|
| Posted: Tue Oct 12, 2004 9:00 am |
|
|
| There is no need or value in starting and stopping receive on a framing error.[/quote] |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Oct 12, 2004 9:56 am |
|
|
| Anonymous wrote: | | There is no need or value in starting and stopping receive on a framing error. |
[/quote]
None whatsoever, except it clears the error, and removes the need for extra code to do it (since you need the code to clear the overrun error).
Best Wishes |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Tue Oct 12, 2004 6:21 pm |
|
|
| Quote: | | except it clears the error |
Actually reading the RCREG clears the framing error. |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Oct 13, 2004 3:08 am |
|
|
| Mark wrote: | | Quote: | | except it clears the error |
Actually reading the RCREG clears the framing error. |
Supposedly...
The advice to do this, originally came from MicroChip, following a problem I was having with the error remaining set. I have left the code in place, since the extra test is tiny, and if the error is allready cleared, will never be called. Without it, I was seeing the communication 'deadlock', about once a week (the system runs continous comms, at 9600bps, transferring about 200cps, 24/7). This then led to a watchdog recovery. With this clear in place, the system never displays the problem.
Best Wishes |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Wed Oct 13, 2004 4:44 am |
|
|
Well there is certainly nothing wrong with doing it that way 
Here is part of my receive routine:
| Code: |
rcstabits = RCSTAbits;
data = RCREG;
// Check for buffer overrun error
if (rcstabits.OERR)
{
RCSTAbits.CREN = 0;
RCSTAbits.CREN = 1;
// we just received a buffer overrun so lets wait
// for a good data byte before we look for the break signal.
Rx_State = WAIT_FOR_BREAK;
}
// Check for framing errors
else if (rcstabits.FERR)
{
Rx_State = WAIT_FOR_BREAK;
}
|
These devices use the 16F876. I haven't experienced a lockup yet. There are 60 of these devices on a test bed that have been running for about 3 years and 57600. The only thing I would suggest is that anyone would cares about "knowing about" framing errors read the status before reading the data. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
