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!

Thanks for your response NKurzman (and for the many, many others you have posted on this forum).
 
I have edited the title of my post to make it clearer that I had solved the problem - which was that the system was using the FRC, not the XO.  That had come about as a result of me using a Harmony project, and it did not occur to me that the writer of the Board Package would have used the FRC until I looked at the config registers.
 
The FRC (which I have not tried to tune) on my PIC32MZ sample is about 2% fast (which is within its spec) and there is some jitter which is obvious on the 'scope when looking at the UART output running at 250kbit/s (which I require for DMX lighting control).
For the record:
1. I did not know that - I will take a look for when I do my PCB design (I'm just using the eval kit at present)
2 & 4. It was looking at the bit timing of the UART output on a 'scope which showed me the absolute error and the jitter.  The 'scope has "RS232 decode", and was struggling to resolve the characters.
3. It was when I did that check using the excellent spreadsheet Microchip have provided that I suddenly realised that the problem was that I was using the wrong clock generator - FRC instead of XO!
 

Equally as important, NEVER trust, or assume anything about, someone else's auto-generated code, especially if it comes out of Harmony.

I have also found that in the Errata sheet it states:
"The UART TX Stop bit duration is shorter than the expected in High-Speed mode (BRGH bit (UxMODE<3>) = 1) for baud rates less than 7.5 Mbps."
I had also noticed this on the 'scope at 250kbit/s.  It explains why the 'scope (Rigol DSO) sometimes struggles to decode the serial data - it's not getting a full bit's worth of "stop" at the end of the character.
 

 PIC32MMZ2064DAR169 - now mentioned in edited OP