Spurious Characters using RS232 with PLL

[duncangray]

My first posting - hope it makes sense.

I have an 18F87K22 running minimal code to try to sort out system clock problems by viewing J0 and J1 (which are toggled using timer_0 and timer_1 ISRs) using a DSO.

I have had system clock success using a 14.7456MHz external crystals and using #fuses HSH, (or HSM) PLLEN and #use delay(clock=58982400) but am getting corrupt/spurious characters in the RS232 stream viewed on an external Crystalfontz serial LCD display or a 2nd PC running Realterm or CCS Serial Input/Output Monitor. This occurs at all Baud rates I have tried from 4800 to 19200. The USART is the internal hardware one #use rs232 (baud=19200, xmit=PIN_C6, rcv=PIN_C7, PARITY=N, BITS=8, STOP=1)

If I remove the PLL (NOPLLEN) and just use the raw crystal clock frequency (#use delay(clock=1475600)) the RS232 is perfect at all Baud rates so I presume I'm doing something wrong with the PLL.

Please can someone point me in the right direction.

[Ttelmah]

Unfortunately, there is an erratum on this chip for the EUSART.
The TXIF bit doesn't get set reliably to say the byte has been sent. It sometimes gets set prematurely.
They document it as only applying at high baud rates, but in fact it applies at high clock rates.
Rewrite the putc function with:

[duncangray]

Ttelmah.

Thank you for the rapid and knowledgeable response and, as a result I have looked at the Errata in the hope that I could swap to the K90. Unfortunately it has the same problem but both are referred to as problems using synchronous transmission. Is RS232 not asynchronous and, if so is the fault still present?

My code uses printf() so I would need to change the library function for printf() to substitute your_putc() in printf(). Please can you tell me how to find printf.

Time to dig out the K&R again!

Thanks, Duncan

[Ttelmah]

Remember you can use printf with any output function, like:

printf(your_putc,"what you want to print");

It is one of the 'good things' in CCS.

It's 'odd'. I came across it on this chip family, when trying to use interrupt driven TX. It just would not work reliably. Ended up using a timer interrupt just slightly slower than the UART byte time, and sending one character in this, from a buffer. Told Microchip, and they referred to the erratum. It appears that it applies to the whole UART, when the clock rate is above perhaps 30MHzish.....
Obviously the timer approach is safe and reliable, but slightly slows the transmission.

Best Wishes