Kenneth C. Fenney says:

I did a fair bit of work on this chip for a client just a few months ago... you are right to clear the overrun condition by clearing and then setting CREN which has the effect of resetting the receive logic-otherwise the hardware won't shift anymore bytes out of the receive shift register if OERR is set.

However, this bit has no effect on the framing error flag which is just a pronouncement that a stop bit wasn't detected when it should have been. This flag is set/cleared every time you read the receive register (RCREG), and it has no deleterious effect on the UART's behaviour - unlike the OERR bit which gums up the works until you reset it. It does mean that you should *save* the framing status immediately after a read, especially if you're running on rda interrupts and may want perform some out-of-band ack/nack or re-send logic.

As far as I can tell, this is the same for all the other PICs with onboard UARTs (well at least the 65, 73A, 74A, and 77) that I've worked with.

M. Adam Davis says:

• Check and initialize the several registers associated with the UART:

     TXSTA
     RCSTA
     SPBRG
     PIR1
     PIE1
     TRISC (TX & RX pins both input)
  

• Follow the suggested initialization order on the data sheet (p.107 and p.109 on the 17c74 datasheet)
• Do NOT use the baud rate tables in the data sheets, Use the calculations instead:

     Fosc/(64(spbrg+1))   BRGH = 0
     Fosc/(16(spbrg+1))   BRGH = 1
  

  (for instance the table for BRGH=1 at 4MHz async says 57.6kbps at spbrg=25, which is incorrect. 9600 is correct for spbrg=25 @ 4MHz. It /looks/ like the BRGH=1 tables are the only ones incorrect, but you should double-check)

• Make certian TRIS for RX and TX pins are BOTH input (counterintuitive, but necessary)

Thomas C. Sefranek's 16C73 USART Serial Port Gotcha List and Source