About STM32H7 PLL configuration and precision

[Gpeti]

Hello,

I've got some questions about STM32H753 PLL setting.

1) There are many configurations of M, N and P parameters that give the same output clock. Are there some configurations that are more precise than others (regarding the output clock) ?

2) The datasheet gives some insight about clock precision, for example:

What means "long term jitter" exactly ? I understood this is the difference between the PLL output clock and the "target" clock" in average, is it correct ? Indeed, I did some test (comparing the accuracy of a timer to an external very precise signal) and I've got the same order of precision (less than 1%). This is consistent but what is annoying is that my source clock oscillator has a precision of 10ppm so it means that the PLL adds a huge imprecision. perhaps it is normal I'm not very familar to PLLs.

3) A tiny inconsistency in the TRM v8 (RM0433):

vs.

Regards

[STOne-32]

Dear @Gpeti ,

Indeed our PLL settings are provided to match different uses cases and so many combinations are offered depending on the input reference.  As example the best match to each any frequency value is to have PLL reference clock input = 1MHz and then using PLL multipliers we may reach any target integer value expected. But if we have a higher input up to 16MHz, we can use the VCOH instead and reach up to 960MHz . It is very important to have VCOL or VCOH within the  [Min / Max] target so the PLL can lock and is stable.    

• What is long term jitter? 

Long term Jitter is the position of clock edge (let say rising) after a certain number (N) of clock cycles versus the expected position in the time scale.

        According uses, number of cycles N may change to fit application requirements.

• What are the effects of long-term jitter?

The effect is that for the N’ cycle, edge is phase shifter versus the expected one. Application should be compatible with that.

if your input clock Jitter is negligible ( 10ppm) :

1. Entering this clock into the PLL, it will be multiplied by a ratio and then divided to come back to same frequency than the one at the input. 
2. After PLL locking sequence, a phase shift exists between clock input and clock output. This is due to propagation delay inside digital part embedded in the PLL (Clock feedback and output clock divider)
3. This phase shift will be modulated by Period Jitter: This is the period variation of each output clock cycle.
4. It will be also modulated by Long-Term Jitter which is the sum of period between two PLL correction performed on each rising edge of input clock.

Here also we can explain what Cycle-to-Cycle Jitter means: This is the period difference between two consecutives output clock cycles.

• Long Term Jitter Standard deviation (Sigma) is expected to be less than 0.1% of input clock period.
• Aging is not expected to be a major contributor of Long Term Jitter.

When we output the clock to a GPIO as output, this will add the I/O and VDD/Rails power transitions and is not just PLL image which is very complex to measure at an I/O level.   Is that possible to share you usage ?

Regarding the documentation remark, many thanks for spotting it - Yes, it may be seen as confusing but with a second lecture it seems correct for me 😉 

1) Odd Division factors are not allowed  , that means  /3  /5 etc..

2) DIVP bitfiled can take only odd values , that means 0x1  , 0x11 

which is equivalent , sorry for the confusion created on the interpretation.

Let me know if it helps you.

Cheers,

STOne-32.

[Tesla DeLorean]

Is there a sweet-spot for the PLL comparison frequency. The F2/F4 wanted it in the 1-2 MHz range

One of the reasons for EVEN dividers into the CPU is that it needs a 50/50 duty cycle, the VCO is more of a pulse generator.

One of the reasons for multiple options to the same frequency is so you can hit all the frequencies on all the PLL's and all the taps to cover the expectations of peripherals, audio and video clocks.

ie USB wants 48 MHz, ETHERNET wants 25, 50 or 100 MHz, LTDC/DSI want magic numbers

You might want to avoid certain frequencies in radio systems, signals / emissions bleeding through CMOS switching noise.

[Gpeti]

Thank you, it is very useful indeed.

My use case is (to simplify) that I need to measure time precisely to control external signals (connected through GPIOs)

I noticed that the timer of the STM32 seems to be not very accurate (or I set it up / used it badly).

Basically there is a difference of around 0.5% of the duration measured by the timer compared to what I expect. I am not allowed to give too much details.

I understand from your explanation that it can be explained by the 0.7% long-term jitter mentioned by the datasheet, right ?

Also I didn't understand : "Long Term Jitter Standard deviation (Sigma) is expected to be less than 0.1% of input clock period." Could you give an example ?

[Gpeti]

Another point. Just to be sure. When you say  "As example the best match to each any frequency value is to have PLL reference clock input = 1MHz" do yo mean it is better in terms of precision ? or just for convenience for the developper ?

[LCE]

> Basically there is a difference of around 0.5% of the duration measured by the timer compared to what I expect.

0.5% of what? Surely the error gets bigger when measuring shorter time periods.

Most often the biggest source of timing errors is that people use the HSI, the internal RC oscillator, which is terrible concerning absolute accuracy and jitter.

Another source might be the measurement setup. Try to use timer's input capture with DMA, that gave my stuff the highest accuracy.

[Gpeti]

For example I measure a duration that is supposed to be around 100ms. The system clock is 400MHz. The timer prescaler is set up for the granularity to be 1us (every timer tick lasts 1us). Instead of measuring 100.000 timer ticks I measure 100.000 - 0.5% so around 500us shorter than expected.

Of course there is an imprecision coming from the software (start and read the timer) but it is few us, not several hundreds.

[LCE]

That's surely no PLL jitter or inaccuracy, but pretty sure your clock or timer setup.

Classic mistake: forgetting the "-1" for prescaler PSC or auto return ARR values.

Example: timer clock = 200 MHz, want: 1µs => TIMx->PSC = 200 - 1;
In case of PSC = 200, error would be about 0.5%

Again, do you use the HSI or an external source?

And reading such input capture values should not take time. Use the timer features like input capture.