Clearing Framing Errors

[EShatara]

I'm having difficulty clearing out framing errors that happen when my laptop (controlling my circuitry) comes out of sleep mode.

My application has a tight loop looking for a received character. I use the timeout feature to look for any usart error or poll user inputs via switches. What happens is all is working fine but when I put the laptop to sleep I get framing errors when I come out of sleep UNTIL a valid character is received by the USART.

I'm using PBP and 18F252

My code is basically:

RXLOOP:
HSERIN 10,NOCHR,[ChrIn]
Goto RXLOOP

NOCHR:
IF RCSTA.1 =1 then 'Framing Error Detected
RCSTA.7 = 0 'Disable the USART
RCSTA.7 = 1 'Re-Enable USART
PulsOut PortC.2,10 'Issue a pulse to see what's happeing
' used for debugging this problem
endif
goto RXLOOP


What happens is when the laptop begins to come up from "StandBy" mode, I get a continuous stream of pulses indicating to me that the framing error has not be cleared. As soon as I transmit a valid character, the pulse stream stops.

I've also tried reading the Rx Buffer and trashing it but that still didn't reset the error condition.

Any help would be greatly appreciated.

Thanks..chris

[mister_e]

Maybe your USART buffer overflow too. Can you try add

DEFINE HSER_CLROERR 1

this will automatically flush the buffer if he's in overflow.

now try without timeout and post what's happening now.

i hope this help...

regards

[EShatara]

Should have mentioned it but I did have

DEFINE HSER_CLROERR 1

in my program. I'm not getting overflow errors as I have a counter to count these events (RCSTA1.1) and the counter is remaining unchanged.

Could the problem be that I need to wait some time between disabling and the re-enabling the usart?

/chris

[mister_e]

pure stupid guess here... what about if you pull an pull down resistor on the RX pin of your DB9 ??? Is when the Laptop goes to sleep output signal are floating level/tri-state ???

[EShatara]

Actually my configuration is as follows:

PCB9 --> RJ11--> Max202---->Pic18F252

On going into standby, the RX line (into the PIC) stays at 5v with the execption of a 5ms +/- pulse as the computer shuts down.

Now on the way up, as soon as I hit the space bar to wake up the computer, it generates a 100ms pulse (H-L-H). The framing error happens here and interestingly not on the way down.

The line is never "floating" since it's being driven by the max202


/chris'

[Bruce]

RCSTA.1 is the overrun "OERR" bit.

RCSTA.2 is the framing error "FERR" bit.

> IF RCSTA.1 =1 then ' Framing Error Detected

If RCSTA.1 = 1 it would indicate an overrun condition not a framing error.

To clear the OERR bit/condition you clear then set RCSTA.4 "CREN", and not RCSTA.7 "SPEN".

This;

RCSTA.7 = 0 'Disable the USART
RCSTA.7 = 1 'Re-Enable USART

Should be this;

RCSTA.4 = 0 ' Continuous receive disabled
RCSTA.4 = 1 ' Continuous receive enabled

[EShatara]

Thanks Bruce,

I just did a quick check on my code and I have it correct in the code. My I had indvertantly used the wrong pin in describing my problem above.

I've done exactly what you suggested to clear out OR errors. It's still the framing error that I'm struggling with.

I'll go back and make sure. It's real easy to switch these bits around.


thanks...chris

[Bruce]

Hi Chris,

Framing errors are normally caused by serial data coming in at the wrong baud rate or noise. Your pulse is causing a logic 0 to be seen where the hardware USART expects to see the stop bit.

If you add a framing error test & a solution to clear it, then you shouldn't see the continuous pulse stream.

Unless you have an ongoing problem with noise pulses or a baud rate missmatch, this should clear the problem, and you should only see the single pulse on entry into the framing error test routine.

ChrIn VAR BYTE
Junk   VAR BYTE

RXLOOP:
   HSERIN 10,NOCHR,[ChrIn]
   GOTO RXLOOP

NOCHR:

' Test for & clear framing error
IF FERR THEN              ' IF RCSTA.2 = 1
    Junk = RCREG         ' Read RCREG to clear error
    PulsOut PortC.2,10 ' Pulse to see what's happening
ENDIF
GOTO RXLOOP

You can test other conditions pretty much the same;

' Test for & clear overrun
IF OERR THEN             ' Test OERR for overrun condition
    CREN = 0                ' Disable receive
    CREN = 1                ' Re-enable & clear OERR flag
ENDIF

' Test for & clear remaining data in buffer
WHILE RCIF                ' Trash left over characters in RCREG
     Junk = RCREG          
WEND
GOTO RXLOOP

[EShatara]

I went back and checked more carefully and it was a typo in my origianal post. I truly am dealing with a Framing error issue. sorry for the confusion.

Since the RX line goes low for about 100ms when the computer is coming out of standby, i thought maybe I would be trying to clear the error while the condition was still holding. So I changed my routine to the following:

IF RCSTA.2=1 'Framing Error
PulsOut Portc.2,10 'send out a pulse for debug purposes
Pause 250 'wait 250ms for condition to clear
'
' now reset the usart
'
RCSTA.7 = 0 'Serial Port Disabled
RCSTA.4 = 0 'Continuous mode disable
RCSTA.7 = 1 'Re-enable serial port
RCSTA.4 = 1 'continuous receive mode
goto RxLoop
endif

Still no luck....only a new character will reset the conditon.

/chris

[Bruce]

Are you saying this doesn't work..?

IF FERR THEN ' IF RCSTA.2 = 1
Junk = RCREG ' Read RCREG to clear error
PulsOut PortC.2,10 ' Pulse to see what's happening
ENDIF

[EShatara]

Sorry I was a bit out of sync with your replies

Yeh I'm still not out of the woods with this one. The following code DOES NOT RESET the error condition

IF RCSTA.2=1 'Framing Error
PulsOut Portc.2,10 'send out a pulse for debug purposes
Pause 250 'wait 250ms for condition to clear
'
' now reset the usart
'
RCSTA.7 = 0 'Serial Port Disabled
RCSTA.4 = 0 'Continuous mode disable - probably not needed
RCSTA.7 = 1 'Re-enable serial port
temp = RCREG 'clear out the RX buffer
RCSTA.4 = 1 'continuous receive mode
goto RxLoop
endif


I added the temp=rcreg to clear out the read buffer. Still no dice.

Looking at the serial input line, it looks very clean. Baudrate is not a problem as I have sent 28,000 characters to the circuitry with one embeded command in the stream and it saw it and acted upon it with out any problem.

I do notice in the DataSheet for the 18F252 that it states for FERR:

"can be updated by reading RCREG and
receive the next valid digit."

Seems like the receipt of a valid digit is the ONLY thing that would clear this error. Basically that is what I am running into. So maybe that's the way it has to be.

/chris

[Bruce]

I'm just curious (haven't tested it), but how about trying to read RCREG without disabling the USART or CREN first..?

I.E. try temp = RECREG, but leave the USART & CREN enabled, and see what happens.

Maybe something like this;

WHILE RCSTA.2=1
Temp = RCREG
PulsOut PortC.2,10
WEND
GOTO WhereEver

I'm curious about this one myself. If reading RCREG by itself isn't clearing the error, then you'll have a continuous pulse.

[EShatara]

Bruce,

Just tried what you suggested and no dice... get a stream of pulses on C.2 until a "real" character comes into the port.

I guess that's just the way the beast works.

Thanks for all you help on this.

/chris

[Bruce]

That is interesting. I setup a simple test sending serial data to an F876A.

With the USART set for 9600bps, sending data to it at 300bps, it sets FERR, and reading RCREG has absolutely no affect on FERR.

Only receipt of a valid character at the correct baud rate (when no overrun condition is present) clears the FERR bit.

The reason Microchip mentions reading RCREG "AND" receiving a valid character to clear the framing error is because if you don't read RCREG first, and it's full, the USART can't receive any new characters, and the framming error can't be cleared.

Reading RCREG doesn't clear the error. It just clears OERR which inhibits transfer of inbound data from SSR to RCREG, and the ability to receive a valid character that's going to clear the framing error.

Unless I were going to use hardware hand-shaking or flow control, I wouldn't even bother with monitoring the framing error bit.

[EShatara]

Thanks again for all the help Bruce....I came to the same conclusion.

/chris