Xtal frequency selection help on STM32H7 with complicated PLL

[jnz]

I am selecting a clock for this project, needs to be a crystal for industrial CAN and other peripherals.

A previous guy specified 25Mhz, but the development used 8Mhz.

We need three PLL outputs with speeds from 3.3Mhz to 96Mhz. The H7’s PLL is pretty complicated and has a lot of multiply and divide options.

In my head, I want to keep the number of multiply as low as possible, but does it actually matter?

Does the 8Mhz clock with more multiplication perform worse than the 25Mhz with lower? I think divide should be “free”, harmless. Assuming quality parts here, 8-12pF or so loading, good routing, low stray capacitance, etc… but no matter what I’m using the PLL and charge pump for everything so does the amount of use significantly matter?

[Siwastaja]

It's all in the reference manual - as long as you stay within the legal range, multiplication can be anything, no difference in better or worse. Choose freely and don't make it more complicated than it needs to be.

Note, there are multiple PLLs, each of which has only one multiplier but several dividers (so multiple outputs). When you need exact frequencies which are not integer multiplies of each other, you cannot use a single PLL, but no worries, just use another PLL then.

Remember to take a good look at the clock tree diagram to see if there are further dividers (like :2) down the tree.

Do you have some weirdly important jitter specs (precision ADC, for example)? If so, not using the integrated PLL at all to drive those would seem like a good idea.

[wek]

AFAIR the 'H7 has fractional-N PLLs, so the question of a particular input frequency is not that pressing (and CAN surely won't be sensitive to somewhat worse purity of the frequency from fractional-N PLL).

Some say that MicroXplorer known today as CubeMX is useful for this sort of checks. I don't use it, but that means nothing. As Siwastaja said, read the relevant chapters of RM and DS.

JW

[Bud]

What is your Phase Detector Frequency? From noise minimization perspective I would select a crystal that uses the smallest clock PFD divider ratio. Each divider introduces additional jitter so your PFD noise accumulates. If say your PFD is 4 MHz I would use a good quality 8MHz fundamental frequency crystal. A 25MHz crystal would require a larger number of divider stages as well as the crystal itself may be an overtone one. The quality of the clock will directly affect the output.

[PCB.Wiz]

I am selecting a clock for this project, needs to be a crystal for industrial CAN and other peripherals.

A previous guy specified 25Mhz, but the development used 8Mhz.

We need three PLL outputs with speeds from 3.3Mhz to 96Mhz. The H7’s PLL is pretty complicated and has a lot of multiply and divide options.

In my head, I want to keep the number of multiply as low as possible, but does it actually matter?

Does the 8Mhz clock with more multiplication perform worse than the 25Mhz with lower? I think divide should be “free”, harmless. Assuming quality parts here, 8-12pF or so loading, good routing, low stray capacitance, etc… but no matter what I’m using the PLL and charge pump for everything so does the amount of use significantly matter?

In any PLL the important numbers are the 'analog' ones  As you guess, the digital parts matter less.

ie The VCO range matters, it needs to be inside the spec window.
The other important number is the PFD (Phase/Frequency detector) that's the lowest compare frequency, that drives the VCO correction voltage.
A higher PFD usually means lower jitter.

Another reason to choose 25MHz over 8MHz is size and availability. 8MHz xtals are trending less common and larger.

If you think you may need high precision in this or future projects, you can also look at 26MHz and 19.2MHz/38.4MHz  clock sources.
Those are common GPS/TCXO numbers.

[Sal Ammoniac]

ST's STM32CubeMX has a screen where you can plug in various crystal frequencies and set the multipliers and dividers and see what frequencies result. It also flags frequencies that are out of bounds.

Here's what it looks like:

[Berni]

ST's STM32CubeMX has a screen where you can plug in various crystal frequencies and set the multipliers and dividers and see what frequencies result. It also flags frequencies that are out of bounds.

Here's what it looks like:

Yep this is the tool you want to be using.

The more complex chips have such a complicated clock setup, that it is impossible to really visualize it without it. Best thing is that any clocks that are set up wrong will light up as red, so you will see any mistake.

The PLL is always accurate because it is phase locked. The only thing you can improve is the phase noise by running it in the regions it likes to operate, but for 99% of use cases the phase noise is too low to be noticeable in any valid configuration. Also notice that the crystal input has a divider before the PLL, this means that you can always divide a fast crystal down to the couple of MHz that the PLL needs.

[jnz]

Ok, so I'm not too far off. The PFD on the STM32H7 seems to be (according to datasheets, two ranges. 1-2 and 2-16)... But they allow in 4Mhz to 50Mhz as the HSE. So there is an initial divider that is outside of the analog hardware. Once you hit the PFD the value must be 4-16Mhz.

So once you are using the PLL to multiple by ANY number, it doesn't matter if it's *4 or *512? That seems a little odd to me. Even though it's locked, it seems like *512 is going to be too high of a clock even internally for a moment before it's divided again.

It makes sense you can't get a slow speed in a small package. Like larger key making a lower tone. I never had to consider this before.

CubeMx does have a super-helpful clock page, but I'm not sure what the math operation is called to fill in 25 / X * Y / Z = 96. So I wrote a quick python script to help me find all the options for a given clock and the limits the chip allows or doesn't. Just brute force with three for loops. I agree this is the tool to use, but I had trouble finding all the common multipliers and dividers I would need. The resolve issues feature is good, but doesn't allow you to enter in all sorts of PLL final values and get the settings required.

It's pretty damn hacky, but I was in a hurry. Doesn't work well for floats because of rounding.

Code: [Select]

freq_input = 25
freq_desired = 96
for div_1 in range (2, 63):
    for mul_1 in range (4, 512):
        for div_2 in range (1, 128):
            freq_calc = freq_input / div_1 * mul_1 / div_2
            if (freq_calc == freq_desired):
                if (freq_input/div_1 >= 1) & (freq_input/div_1 <= 16):
                    if (freq_input / div_1 * mul_1 >= 192) & (freq_input/div_1*mul_1 <= 836):
                        print ("DIV_1 ", div_1, "MUL_1 ", mul_1, "DIV_2 ", div_2, "== ", freq_calc)


[Siwastaja]

The more complex chips have such a complicated clock setup, that it is impossible to really visualize it without it.

I totally agree such helper tools are useful. But impossible? Are you serious?

The first time EVER I used STM32H7, I think it took... maybe two-three hours to
1) mentally understand the clock tree
2) get the multipliers and dividers as I want them
3) write code that does that, and which worked the first try

Basically the same diagram is in the manual. All Cube does is automatically calculate and update cell colors, pretty much exactly what Excel does.

I did it on pen and paper the first time. In the end, it is less than ten calculations, all elementary school level (multiply, divide, see if within accepted range).

Come on, it's not that complex.

[Sal Ammoniac]

The more complex chips have such a complicated clock setup, that it is impossible to really visualize it without it.

I totally agree such helper tools are useful. But impossible? Are you serious?

The first time EVER I used STM32H7, I think it took... maybe two-three hours to
1) mentally understand the clock tree
2) get the multipliers and dividers as I want them
3) write code that does that, and which worked the first try

Basically the same diagram is in the manual. All Cube does is automatically calculate and update cell colors, pretty much exactly what Excel does.

I did it on pen and paper the first time. In the end, it is less than ten calculations, all elementary school level (multiply, divide, see if within accepted range).

Come on, it's not that complex.

Did you do those calculations using a calculator or on paper? 

[PCB.Wiz]

So once you are using the PLL to multiple by ANY number, it doesn't matter if it's *4 or *512? That seems a little odd to me. Even though it's locked, it seems like *512 is going to be too high of a clock even internally for a moment before it's divided again.

Yes, there is a range limit on the VCO, that depends on the MCU design details.  Most VCOs are designed to cover somewhat over 2:1 sweep range and rely on binary dividers to do the rest.
Some MCUs define what that VCO range is, & from the comments on the clock tool above, it says " It also flags frequencies that are out of bounds." so the SW checks that for you.
eg if you enter 10MHz  * 512, that will be outside the VCO range.

[Berni]

The more complex chips have such a complicated clock setup, that it is impossible to really visualize it without it.

I totally agree such helper tools are useful. But impossible? Are you serious?

Maybe my short term memory is that bad then. I know i would have to write down the tree on paper with the corresponding numbers and MHz numbers at each stage to figure what clock speeds id get and if they are valid.

As opposed to the older simple MCUs where the clock tree was so small i could just look at a single datasheet page and write down 4 or 5 register settings to configure everything including the PLL.

Or i could just run this CubeMX tool and have the whole clock tree sorted in literally minutes (including getting the source code to set it up)

[Siwastaja]

Did you do those calculations using a calculator or on paper? 

Thank you for this opportunity to clarify. Yes, I did use a calculator instead of doing that long division thingie on paper. Cheating, I know .