Nice tests.
What MCU did you test with, with what clock setups ?
I assume "any logic clocked by the MCU's internal clock generator" includes no PLL operation (so PLL jitter is not in the test here) ?
I guess that makes sense, as MCUs are inherently noisy environments, with GND and VCC bounce that varies based on what logic is switching, and that varies by opcode and memory access and even address values.
Maybe the simple built XTAL oscillators are a bit worse there, than external CLOCK sources, as even the sine threshold will have that small but finite noise imposed on it ?
Did you try External CMOS Clock -> MCU > ClockOutput with MCU in IDLE & then NCU running memory patterns ? The IDLE case should be close to ideal / minimal added jitter ?
Apologies for delay.
I tested with a microchip ATSAMD51J19A (Cortex M4 +) on an adafruit arduino clone (Metro M4 express) board (
https://learn.adafruit.com/adafruit-metro-m4-express-featuring-atsamd51/downloads)
The clock setup is an external CMOS clock generated by a separately powered CMOS square-wave OCXO, level shifted with a 74LVC1G17 schmitt trigger, then delivered to the XOSC0IN pin, and from there routed to a 1:1 generic clock generator, and from there to the timer/counter and programmable logic peripherals. There is no PLL in the clock path.
Using a minimally loaded FPGA powered from its own LDO to generate timing signals gives very good results - When loaded with only a flip-flop chain, it is indistinguishable as a stop trigger generator from discrete flip-flops, and when used to divide the main clock to provide a coherent PPS, the measured jitter is equal to the TDC7200's specified noise floor.
However, I have indirectly done a CPU load experiment using a PPS signal from a GPS unit. In the attached figure, I have plotted the time between consecutive PPS pulses as measured by my interval counter while the receiver is tracking either 1 constellation or 2. If you ignore the gross quantization error, the increased jitter when running in 2 constellation mode (red) is clearly visible, including some peculiar modulated jitter, presumably related to increased processing load (I suspect the mechanism here may be different: i.e. an oscillator frequency shift related to voltage, rather than a voltage threshold issue).
One of the subsequent quirks I discovered with the TDC7200 is that you don't strictly need an accurate stop signal, because you can slightly misuse one of its measurement modes to obtain a time interval directly referenced to an external clock. So, at the cost of not being able to calibrate the TDC7200's internal latency, I can eliminate the issue of the MCU's clock jitter from my measurements.
I'll have a go with loading down the MCU, as the same TDC7200 measurement trick also permits direct measurement of the MCU's clock jitter.