STM32H5 PLL Nfract issue

[hijax_pl]

Hello,

I am using STM32H503 for precise time measurement hence I need to tune the PLL that output frequency compensates the voltage or temperature drift of the HSE crystal.

My setup is:

- Clock configured as HSE=16, M=, N=337, Nfrac=4096, P=2 which should give HCLK=180MHz
- External, high class reference GPS clock (1PPS) connected to TIM1 as ETR.
- TIM2 CH1 in IC/TRC mode with DMA readout to measure the HCLK.

The procedure is as follows:
- DMA reads TIM2_CH1 CC values into buffer in circular manner (size of buffer is 30 dwords)

- on every HT/TC interrupt I am averaging measurements, taking into account only those within 2% of target frequency

- I am calculating the HCLK error, and correction to be applied to PLL1 Nfrac register.

Update of the Nfrac is done according to to RM492, i.e. to enforce 0->1 transition of the RCC_PLL1CFGR_PLL1FRACEN and later wait for RCC_CR_PLL1RDY to become 1.

This is done in incremental way, one can say algorithm tries to find sweet spot, i.e Nrac values that gives smallest HCL error. Typically, with this setup I am achieving 0.01-0.03ppm of precision using typical HSE crystal with 20 or 30ppm frequency tolerance.

Yet, I frequently see the update of the Nfrac does not change HCLK.

Not always, sometimes, but this behavior fools my algorithm.

As en example, here is a log showing timestamp of USART reception, HCLK from previous 15 measurements and calculated current NFrac.

[10:44:00.007] RX: 179994460,4061
[10:44:15.006] RX: 179995763,4081
[10:44:30.006] RX: 179997716,4101
[10:44:45.006] RX: 179997717,4121
[10:45:00.007] RX: 179997717,4141
[10:45:15.006] RX: 180000972,4141
[10:45:30.006] RX: 180000321,4126
[10:45:45.006] RX: 180000321,4121
[10:46:00.007] RX: 180000321,4111
[10:46:15.006] RX: 180000321,4101
[10:46:30.006] RX: 180000321,4091
[10:46:45.006] RX: 180000322,4081
[10:47:00.007] RX: 180000322,4071
[10:47:15.006] RX: 180000323,4061
[10:47:30.006] RX: 179997881,4066
[10:47:45.006] RX: 179995440,4076

According to RM: "The PLLxRDY flag is set when the PLL lock is detected. The lock detect circuit uses a window comparator that asserts the flag when the output frequency is within a ±2% window of its target value."

For HCLK=180MHz, 2% is 3.6Mhz.
With my PLL setup, change of FracN by 1 should result in HCLK change of 65Hz.

From the observation I can notice that:

Changing NFRAC does not always result in an immediate PLL response, despite the correct FRACEN sequence.

Is it possible that the PLL has an internal averaging mechanism or sigma-delta filter that ignores small changes in FRACN if the new value differs from the previous one only by ±1-2 (because the effect of ~±65 Hz is "below the line of sight")? Or change in FRACN does not change HCLK as the PLL window comparator sees that VCO-out is OK-ish?

If this is a case, how one can effectively use FracN?

Regards,

Arkadiusz

[hijax_pl]

I did an experiment.
Starting from HCLK=210Mhz (HSE=16,M=15,N=393, FRACT=6144, P=2), every 16s I am decreasing FRACN (green line) and start collecting HCLK measurement every second (orange line).

With FRACTdelta=65Hz, every change of FRACT shall result in 65Hz decrease.

here are the results:

For the whole test (93 measurements, 24min of test) we see decrease of .... 5945Hz which means in average 63.92Hz per FRACN step. But, as you can see, PLL response is not following the FRACN setting properly.

Not in product documentation, but in the HAL sources one can find clue that:
„Wait at least 2 CK_REF (PLL1 input source divided by M) period to make sure next latched value will be taken into account.” - apparently HAL designers are using completly other documntation knon to public.

With my setup it is ~3us thus I embedded 1ms delay:

No rapid changes, however curve does not comply to the PLL VCOout equation from RM492

Next test is with changing NFrac by 5 every 16s. WIth no delay , i.e. very short FRACEN pulse.

Some hiccups are visible but the overall PLL response in linear.

To sum up, indeeed the delay is needed, but  should it matter if this is 3us or 1ms? Especially that setting FRACEN does not switch PLL to integral mode, one must still  latch 0 in SH_REG. 

This implies that after setting FRACEN back to 1, and waiting for PLL1RDY to became 1, I should be able to safely set FRACEN=0, to create "long delay" before next PLL tuning session happens.

But there is more.. Here is a chart started at the moment, HSE correction achieved +/-1ppm thus FRACR is not changed anymore. But there is still some very slow osculation visible over 2min period of time (measurements taken every 15s as averages)

Will appreciate technical info how RCC PLL really works, what are the other important aspects that are not documented in RM? :)

[hijax_pl]

To sum up:

While tuning PLL1 output via dynamic changes to PLL1FRACR, I've observed that the PLL response is not linear, even when proper timing is ensured (e.g. 1 ms delay after writing FRACR before setting FRACEN = 1).

According to the formula in the reference manual, each FRACN step should result in a predictable frequency change (e.g. ~65.1 Hz for given PLL settings). However, in practice:

• The PLL sometimes does not react immediately to FRACN changes, even with delay
• The output frequency (HCLK) response is nonlinear, especially for small step changes
• The effective frequency sometimes lags, jumps in bigger steps, or stays flat temporarily

I suspect this behavior is due to the internal sigma-delta modulator, which averages small changes over time, rather than applying them instantly.

For applications that rely on precision (e.g. GPS-disciplined clocks), it’s important to know that: The PLL fractional response may be nonlinear and dynamic due to sigma-delta averaging, and not every change to FRACN leads to an immediate frequency update.

This would help developers design safer algorithms when tuning the PLL in runtime with high-resolution references (e.g. GPS 1PPS, OCXO).

Could ST consider documenting this effect in the RM/DS or explain what is going on and how to overcome this phenomena?

[hijax_pl]

Any help from ST on the matter?