PIC32 UART bit timing inaccurate and unstable: SOLVED - for information
I spent quite a long time wondering why - when I looked at the Tx output of the UART on a storage 'scope - the timing seemed a bit erratic, and generally about 2% fast, given that the dev board I am using is clocked with a crystal oscillator. That should be pretty much dead on - right?
My hardware is an Eval kit D320010 which has the PIC32MZ2064DAR169 processor.
Well. I started to think the PLL must be misoperating. I found a really useful spreadsheet tool at h_t_t_p://microchip.wikidot.com/local--files/32bit:mx-osc/PIC32_OSC_CONFIG_v1.1.xlsx
Take note that this has separate tabs for the MX and the MZ clock systems - there are subtle differences.
This led me to look at the values in the configuration register DEVCFG2.
I found that the 'board pack' for the dev board had most helpfully selected the internal free running clock, so I wasn't using the crystal at all.
The DEVCFG2 config reg is set up in the C file initialization.c
I have adjusted these values from the default:
#pragma config FPLLIDIV = DIV_1
#pragma config FPLLRNG = RANGE_5_10_MHZ
#pragma config FPLLICLK = PLL_FRC
#pragma config FPLLMULT = MUL_50
#pragma config FPLLODIV = DIV_2
to read:
#pragma config FPLLIDIV = DIV_3
#pragma config FPLLRNG = RANGE_5_10_MHZ
#pragma config FPLLICLK = PLL_POSC
#pragma config FPLLMULT = MUL_50
#pragma config FPLLODIV = DIV_2
All sorted. Now, the bit timing is - as expected - spot on.
Big thanks to Robert Smith, who authored the spreadsheet - it really helped me understand the complexities of the clock distribution.
A pity the author of the Board Pack made the FRC choice!
post edited by boatbodger - 2019/11/20 11:39:27