Nucleo-144 STM32H755ZI vs STM32F767ZI

[lserrnt]

Hey there,

I am facing a problem with the clocks on the STM32H755ZI. When I let a timer run at 50 kHz I get only smt. like 49.92 kHz out of it with sigma = 13 Hz. So there is at any frequency a steady offset of -1.2% and a sigma deviation of 0.03%. I have chosen as HSE the Crystal/Ceramic Resonator and the APB2 of the timer runs at 200 kHz.

With the Nucleo 144 STM32F767ZI I get for similar settings basically 0% frequency offset and sigma deviation of only 0.0003%. So I am wondering what has changed between these discovery boards

H755:

https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html

F767:

https://www.st.com/en/evaluation-tools/nucleo-f767zi.html

they both have this X4 crystal at 25.000 MHz and several others.

So do you see any way how I can achieve a higher frequency stability? Or what I might have to change in CubeIDE to activate a more accurate crystal on the H755 board? 

Thanks a lot for any help 🙂

[Issamos]

Hello @lserrnt 

I suggest you to do a benchmark using all possible configuration and all possible clock sources for your application and then you can find the best configuration for your project.

Best regards.

II

[Peter BENSCH]

Hi @lserrnt

Both NUCLEO you mentioned do not have a mounted crystal at HSE and are supplied by the MCO of the ST-LINK for cost reasons. In your screenshot of the clock tree, however, you can see that you are not using the option BYPASS on the HSE, but Crystal/Ceramic Resonator. So it could be that the HSE is frantically trying to make a non-existent crystal oscillate and is therefore generating a deviating frequency for the STM32H755.

Unless you have soldered on a crystal of 8MHz, changed the solder bridges (SB72, SB3, SB4) and fitted the corresponding capacitors, you should stay with the MCO of 8MHz from the ST-LINK.

In this context, please check the stability and accuracy of the frequency at the MCO, e.g. at SB72.

Regards
/Peter

[lserrnt]

Hey Peter, thanks for your reply 🙂

I checked the frequency of SB72 and fixed the configuration. With a primitive osci measurement I got something like 7.989 MHz out of it. I couldn't do a sigma check, but I didn't appear extremly stable to me. The results are basically the same as before. My timer signals are still deviated with a much bigger sigma. And on the F767 I had the same wrong setup, but somehow it appears to work. I'll check maybe the SB of the MCO on the F767 to check whether I get a perfect 8 MHz there. Is it possible that this crystal from ST-LINK is just a bad one? I thought it would be more stable than this and more accurate.

My configuration looks like this

[Peter BENSCH]

Well, the ST-LINK is clocked by an oscillator X1 with 25MHz (no crystal). I don't currently know if the clock to MCO is derived from this oscillator (probably), or from the HSI. Since the oscillator has a specification of max 50ppm, its frequency deviation cannot be significantly influenced by environmental conditions such as load capacitors and can therefore be assumed to be correspondingly accurate. You can check MCO with a suitable frequency counter with corresponding accuracy.

Independently of this, you can of course also set a suitable crystal on X2, of course also make the necessary changes and then use its clock as input for the H755.

Regards
/Peter

[Piranha]

https://community.st.com/t5/stm32-mcus-boards-and-hardware/how-to-change-the-stlink-v3e-mco-hse-frequency/td-p/218882

The documentation is wrong, the support stuff ignores everything... Isn't it fun? 😉

[MasterT · Accepted solution]

To have stable, crystal based clock, you need to re-program STLink to output 8.33 MHz (25/3). Than configure MxCube to this new frequency.

[AScha.3]

not sooo difficult, to get desired master clock

+ also : why they (STM) not set MCO to 8 MHz, as before ??? (here i show this also : DivQ1 -> mco1)

[lserrnt]

Thank you. This solved my problem for now!! 🙂

[lserrnt]

Thank you too 🙂