Overrun error oerr in uart

[raman00084@gmail.com]

I am using dsPic33ep512mu810. In that i am getting overrun error.
For example:

There are 2 while loops. In the first loop if i get 9 'A', then it will break and come to the second loop.

If i send 9 'A' THROUGH DOCKLIGHT SOFTWARE it is working correctly.
If i put the delay_ms(500); then i am getting oerr error.

[bkamen]

That's really not how you want to write that.


First -- IRQ based RS232 == Good.

But keep it simple. No printf in your INT_RDA routine.
Avoid jumping to subroutines in the ISR. Keep everything right there if you can.



You should be
* snagging the char,
* stuffing into a buffer,
* doing buffer management.

Any other cleanup like
* setting received char flags or maybe a count or pointers if you have a ring buffer
* clearing the IRQ flag (if needed - depends on the PIC.)

In your main loop, you don't use a delay. write your main loop to free run and if there's a change in RS232 RX buffer status, then do something about it.

Let your main loop run as fast as it can.

Also, I don't know why you have a call to read the UART from MAIN and an IRQ which is where you should be getting any data from the UART.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[Ttelmah]

and be aware, you can't just clear the OERR bit. You have to read the
data from the UART buffer before this bit will clear. Your clear in the main
won't work.

Generally, having any routine inside the interrupt and outside, will result
in the warning 'Interrupt disabled to prevent re-entrancy', and mean that
interrupts won't be called while you are in the 'main' version of the
routine. Not the way to work. You don't show us what is in
uart_flush_uart1 or alaram_vib
I's guess that one of these actually contains a delay. Result interrupts
are disabled for the delay out in the main code, and an automatic overrun...



General rules are:
1) Have interrupt handlers _only_ do the job that the interrupt signals
needs to be done. Keep them as short and quick as possible.
2) If complex jobs need to be done based on what has happened, set a
flag and do this out in the main code.
3) Avoid anything involving delays in interrupts (break this only with
short 'delay_cycle' type delays required to synchronise with hardware).
4) Avoid calling anything both inside the interrupt and in the main code.
If a serial is handled by the interrupt, all it's operations should be done
using the interrupt.

Also, change the interrupt like: