EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

framing error

Started by krishnap January 27, 2004
hi all
i am using the pic 18f252.I am using the receive interrupt of the USART in which i just check for the incoming data and also check if there are any framing error and overflow error in the incomming message(RCSTAbits.FERR and RCSTAbits.OERR).
but only in some cases i have framing errors (I make port pins high if RCSTAbits.FERR == 1).what is that error ,when does it happen and what care shuld be taken so that i do not miss on these frames that are comming.
 
waiting for a reply
 
reagards
krishna

______________________________________
Micro-IAS mailserver for domain microtechnologies.net
Microtechnologies India Ltd.
http://www.microtechnologies.net

--- In , "krishnap" <krishnap@m...> wrote:
> but only in some cases i have framing errors (I make port pins high if
RCSTAbits.FERR == 1).what is that error ,when does it happen

It sounds like the clock is off a bit on one side or the other. A framing error is
when the receiver doesn't see the right amount of time between the start
and stop bits for the baud rate that it thinks its running at. If one side or the
other is running a little too fast or too slow then you will see this error
intermittently. Another possiblility is noise.

What is your clock source for the PIC? Is it a crystal? If not then that is likely
your problem as any other clock source is not accurate enough and will
probably result in errors like you are seeing.

--Scott


hi
I am using a crystal of 11.0592 MHz with a SPBRG value of 5 (which makes a baud of 115200 ).
what do you suggest to safegaurd against framing error.I am communicating with a nokia 5110 mobile which also works at the baud of 115200 and  yes you are right the framing error does not always arise it is only when i receive certain types of farme from the mobile(Receiving a new message).
what all can be done to AVOID THIS ERROR.
 
 
thanks
krishna
 
 
--- In p...@yahoogroups.com, "krishnap" <krishnap@m...> wrote:
> but only in some cases i have framing errors (I make port pins high if
RCSTAbits.FERR == 1).what is that error ,when does it happen
 
It sounds like the clock is off a bit on one side or the other.  A framing error is
when the receiver doesn't see the right amount of time between the start
and stop bits for the baud rate that it thinks its running at.  If one side or the
other is running a little too fast or too slow then you will see this error
intermittently.  Another possiblility is noise.
 
What is your clock source for the PIC?  Is it a crystal?  If not then that is likely
your problem as any other clock source is not accurate enough and will
probably result in errors like you are seeing.
 
--Scott


______________________________________
Micro-IAS mailserver for domain microtechnologies.net
Microtechnologies India Ltd.
http://www.microtechnologies.net

The longer the continuous received frame is, the higher the sampling
position error will become. Is there hand shaking available so as to
periodically interrupt the transmission? That should resolve the
problem, by allowing the receiver to resync itself.

Chad
--- krishnap <> wrote:
> hi
> I am using a crystal of 11.0592 MHz with a SPBRG value of 5 (which
> makes a baud of 115200 ).
> what do you suggest to safegaurd against framing error.I am
> communicating with a nokia 5110 mobile which also works at the baud
> of 115200 and yes you are right the framing error does not always
> arise it is only when i receive certain types of farme from the
> mobile(Receiving a new message).
> what all can be done to AVOID THIS ERROR. > thanks
> krishna > --- In , "krishnap" <krishnap@m...> wrote:
> > but only in some cases i have framing errors (I make port pins high
> if
> RCSTAbits.FERR == 1).what is that error ,when does it happen
>
> It sounds like the clock is off a bit on one side or the other. A
> framing error is
> when the receiver doesn't see the right amount of time between the
> start
> and stop bits for the baud rate that it thinks its running at. If
> one side or the
> other is running a little too fast or too slow then you will see this
> error
> intermittently. Another possiblility is noise.
>
> What is your clock source for the PIC? Is it a crystal? If not then
> that is likely
> your problem as any other clock source is not accurate enough and
> will
> probably result in errors like you are seeing.
>
> --Scott >
>
> ______________________________________
> Micro-IAS mailserver for domain microtechnologies.net
> Microtechnologies India Ltd.
> http://www.microtechnologies.net
>


=====
My software has no bugs. Only undocumented features.

__________________________________



(This response is being re-posted on-line at yahoo because
yesterday's off-line post was bounced by yahoo for some reason).

I spent a LOT of time last year interfacing to a Nokia 5110 with
PIC's. Thing is, 115,200k is massively high for a little embedded
processor. I had to set up some fancy buffering, which isn't easy
when the packet size from those silly Nokia's often exceeded the
total RAM capacity of the PICs I was using. (C74, F628 and F876's)

The point I am making is that if you spend too much time trying to
process the stream from within the interrupt you may be getting
overruns which are not being flagged properly. The overrun error may
be being cleared as you exit the interrupt, meanwhile a successive
byte may have already started and the UART is misinterpreting a
midstream data as a start bit. This will surely give you framing
errors. Here is _some_ of my handler, which I now see, didn't bother
to check for framing error as; 1. I didn't think it likely to occur
and 2. If it did occur there is no means of recovery and no need to
worry because the Nokia would eventually resend the block anyway. void interrupt isr(void)
{
#if defined (_16C74) || defined (_16F876) || defined (_16F628)

// SCI (Serial Communications Receiver) interrupt
while(RCIF) { // set when SCI receive register is loaded
if (OERR) {
CREN = 0; // clear the overrun error
CREN = 1;
} // we don't need to check framing error because it
will be
// cleared, if set, when RCREG is read
fifo[fifoin++] = RCREG;
if (fifoin == FIFOSIZE) fifoin = 0;
if (fifoin != fifoout) b_fifoloaded = 1;
// if the buffer catches up to itself, too bad, we
will
// eventually get a checksum or other error and do a
reset
#if defined(PICDEM2) && defined(DIAGS_OK)
PORTB = fifoin | 0x60;
#endif
}

--- In , "krishnap" <krishnap@m...> wrote:
> hi all
> i am using the pic 18f252.I am using the receive interrupt of the
USART in which i just check for the incoming data and also check if
there are any framing error and overflow error in the incomming
message(RCSTAbits.FERR and RCSTAbits.OERR).
> but only in some cases i have framing errors (I make port pins high
if RCSTAbits.FERR == 1).what is that error ,when does it happen and
what care shuld be taken so that i do not miss on these frames that
are comming.



The 2024 Embedded Online Conference