Electronic – PIC datasheet is unclear on clearing framing error

errorpicserialuart

On the PIC16F1829, FERR reflect the framing error status of the top byte in the two byte serial receive FIFO. Thus, assuming no new bytes arriving with framing errors, two reads of RCREG should always clear FERR.

However, it is possible I'm reading way too much into this Note in the PIC16F1829 datasheet for the USART. The relevant section is 26.1.2.4 on page 287:

If all receive characters in the receive FIFO have framing errors,
repeated reads of the RCREG will not clear the FERR bit.

This seems to imply that if both bytes in the FIFO had framing errors, FERR would be stuck forever. This seems a little unlikely to me but, at the same point, the datasheet describes how to force clear FERR by resetting the EUSART.

Does anyone have any clarification? I was going to count if consecutive bytes resulted in a framing error but if I don't have to, that would be nice!

Best Answer

There is a subtlety here which the datasheet does not clarify but one of the application notes does (AN774).

The FIFO, as far as it goes, is RCREG + a 1 byte buffer. Plus RSR - the receive shift register.

FERR is never updated unless RCREG is. The act of reading RCREG allows any waiting buffer byte to move into RCREG - this simultanously updates FERR (always) and RX9D (if appropriate). Thus we have three error type scenarios:

  1. One bad byte in RCREG and one ok byte in the buffer: FERR is set, RCIF is set.
    Reading RCREG causes the good buffer byte to move into RCREG along with its framing status.
    Now FERR is clear, RCIF is set.

  2. One bad byte in RCREG and no bytes in the buffer: FERR is set. RCIF is set.
    Reading RCREG causes RCIF to clear. No action is set on FERR. It remains set until a good byte arrives into RCREG.

  3. One bad byte in RCREG and one bad byte in the buffer: FERR is set. RCIF is set.
    Reading RCREG causes the buffer byte to move into RCREG along with its bad framing status.
    Now FERR is set, RCIF is set. Buffer is clear. Situation is now as per (2) above.

For situation 3, repeated reads of the RCREG will not clear the FERR bit. Which is exactly what the note says.

Edit: Note the implication of scenario (1). If you read RCREG in this case, FERR is not valid for the byte you just read. You must check FERR before reading RCREG.

Related Topic