PIC18F1320 Receive UART data corruption

[RayJones]

I have been battling with a problem where async characters received from the EUSART were occasionally corrupted.

To test, I wrote a loopback program on the PIC that simply echoed whatever was received back to a terminal program on a PC.
I then created a file full of "U" 0x55 characters, because this is in effect a nice steady square wave in 8N1 mode.

Randomly you would see a non "U" come back to the PC.

I had otherwise proven the Tx side was 100% OK by doing a similar test sending direct from the PIC.

What I discovered is CCS when configuring the EUSART chose to set BRGH in the TXSTA register, which in combination with 16 bit mode (BRG16 in BAUDCTL) makes the data recovery module in the UART be driven by a clock x4 the baudrate.

A x4 clock feeding a 3 bit majority detector sounds awfully dangerous, especially with asynchronous clocks.

I changed the registers to clear BRGH, forcing x16 into the data recovery, and divided the baud rate divider by 4 to match, and the data corruption issue has disappeared.

I'm thinking this is more an issue with the PIC's hardware, but it is not assisted by CCS's chosen configuration.

For reference, I was only using 9600 baud, 40MHz processor clock (PLL on) - which works out to be a BRG value of 260 with BRGH=0 BRG16=1.
I get clean reception.

The Compiler used a BRG of 1041, BRGH=1 BRG16=1 and corruption was a frequent reception issue.

Cheers, Ray

[Ttelmah]

260, is slightly the wrong BRG value....
Should be 259. With 260, you are 'out' by 0.5%, against 0.16% the other
way with 259.
The CCS settings, would normally be OK, but there is a fault applicable to
most of the EUSART modules, where if using the settings, with both BRGH
high, and BRG16 enabled, the sample points can be generically one
clock 'later' than it should be. It exists as a separate erratum, for several
of the chips, and has been seen on most with this module....
The margin when the clock at the other end is slightly fast, then becomes very poor.

Best Wishes

[bebeto]

i have problem using 40mhz xtal. But when run in proteus all work fine.

[RayJones]

OK, 259 probably is a better BRG choice, and is confirmed in the device's data sheet for 9600 / 40MHz, thanks for pointing the error out.

The point still applies that the CCS compiler should pick a more reliable operation mode if there is a known issue with the EUSART and the x4 clock into the data recovery unit.

As for the display dump shown, you say 40MHz crystal.
You should have a 10MHz crystal fitted and enable the PLL using the H4 option in the device fuses....

Cheers, Ray

[RayJones]

Just signed up as a user to get notifications