INT_RDA not detected, need more help

[arunb]

Hi,

I read a previous post where it was said that the USART could get an overrun error

I would like to know how I can detect this error. In my program I am using the INT_RDA interrupt sometimes this interrupt is not generated, one of the remedies suggested was that the #use rs232 directive must contain the ERROR parameter, this would clear the error bits.

It was also suggested that I should clear the bit manually twice , by polling for the error bit..

Kindly advise how I can do this.....??


thanks
arun

NOTE: The use of the error parameter has improved the performance of the communication of my application, although I notice the problem is still there...

[Humberto]

It's not feasible to help you if we doesn't know:

1) The compiler version.
2) The microcontroller you are using.
3) The header and configuration settings.
4) The lines of codes involved in the problem.
5) The routine to service #INT_RDA.
6) Minimum hardware description.

Regards,

Humberto

[mfilion]

[Neutone]

This is right out of the data sheet.

RCSTAx: RECEIVE STATUS AND CONTROL REGISTER
bit 7 SPEN: Serial Port Enable bit
1 = Serial port enabled (configures RX/DT and TX/CK pins as serial port pins)
0 = Serial port disabled
bit 6 RX9: 9-bit Receive Enable bit
1 = Selects 9-bit reception
0 = Selects 8-bit reception
bit 5 SREN: Single Receive Enable bit
Asynchronous mode:
Don’t care
Synchronous mode - Master:
1 = Enables single receive
0 = Disables single receive
This bit is cleared after reception is complete.
Synchronous mode - Slave:
Don’t care
bit 4 CREN: Continuous Receive Enable bit
Asynchronous mode:
1 = Enables receiver
0 = Disables receiver
Synchronous mode:
1 = Enables continuous receive until enable bit CREN is cleared (CREN overrides SREN)
0 = Disables continuous receive
bit 3 ADDEN: Address Detect Enable bit
Asynchronous mode 9-bit (RX9 = 1):
1 = Enables address detection, enables interrupt and load of the receive buffer
when RSR<8> is set
0 = Disables address detection, all bytes are received, and ninth bit can be used as parity bit
bit 2 FERR: Framing Error bit
1 = Framing error (can be updated by reading RCREG register and receive next valid byte)
0 = No framing error
bit 1 OERR: Overrun Error bit
1 = Overrun error (can be cleared by clearing bit CREN)
0 = No overrun error
bit 0 RX9D: 9th bit of Received Data
This can be Address/Data bit or a parity bit, and must be calculated by user firmware


So to test for framing errors

[arunb]

Hi,

The details are given below, please note that the error still comes up even while using the ERRORS parameter, also when it is cleared.

Please suggest how I can clear /reset the USART module..

thanks
arun

Compiler Version : PCM 3.169
Microcontroller : PIC 16F877


#use delay(clock=4000000)
#use fast_io(B)
#use fast_io(D)
#use fast_io(A)
#use rs232(baud=9600,xmit=pin_c6, rcv=pin_c7,parity=n,brgh1ok,errors)

void main()
{

initialise();

do
{
restart_wdt();

if (RS232_ERRORS!=0)
RS232_ERRORS=0; //To clear the error


if (bShowField==1)
{
showfielddata();
bShowField=0;
}


} while(TRUE);

}


#INT_RDA
usart_isr()
{
disable_interrupts(INT_TIMER1);

if (nUSARTCmd==0)
get_command(getc());
else
process_command(getc());

enable_interrupts(INT_TIMER1);
}

[mcafzap]

I use the following, within the 'main' loop, to pick up both overrun and framing errors:


#byte RCSTA = 0x18
#byte RCREG = 0x1A

if (RCSTA & 0x06){
RCSTA = 0x80;
j = RCREG;
j = RCREG;
j = RCREG;
RCSTA = 0x90;
}



Steve

[arunb]

Hi,

How does one clear the error ??? also how to prevent it.????

cheers
arun

[Ttelmah]

[Humberto]

Hi Arunb,

Ttelmah made a brigth description concerning how to prevent frame and overrun errors.
Below you have my small contribution:
I made some changes in your code. I assume you are receiving a char, not a string.

Best wishes,

Humberto

[Mark]

The code posted could still present problems since you are not always reading the char when the int occurs. Also it is not necessary to disable interrupts inside an interrupt.

[Neutone]

This routine checks for a framing error that indicates a bad baud rate. The bad baud rate indicates a need to change baud on the fly. Dealing with an overrun error should be just as easy. Remember you must always clear the buffer for a new byte by reading the it. The errors are cleared by the built in getc() function and stored in RS232_ERRORS. If you assemble this you will see that it is a very small routine.

[arunb]

Hi,

Thank you very much for the help.

You say the error is due to a bad baud rate, I am using a 4 MHz xtal , will changing to 20 Mhz improve things ???

cheers
arun

[Pete Smith]

[Mark]

For a 20MHz or a 4MHz clock and 9600 baud rate, the error rate if 0.16% which is fine. You actual baud rate will be 9615.

Your orginal routine did not always read the data byte from the receive register. This is important to do or else you won't get another int!

[Neutone]