STM32H7xx RTC accuracy problems

[JOwen.1]

Have several boards with problems keeping time accurately. We calibrate each board in factory test, but some boards have very large errors in the 1 Hz calibration signal and very jittery frequency readings. To make it more interesting, when there is less activity on the PCA the calibration clock output tends to stabilize at a frequency that can be calibrated.

We have tried changing the 32 KHz crystal and load cap's, but that does not seem to have any effect. Boards that exhibit this problem can loose several minutes of time in 24 hours - not acceptable for a modern clock!

Clues:

1. When the calibration output goes wonky, it typically drops slightly. For example, it might go from a stable reading of 0.999962 Hz to 0.998637 Hz and jump around a good bit.
2. The same board can be good or bad. For example a board on our tester can output a good or bad frequency on a given power cycle. Also, when we load a very simple test program that only turns on the calibration output and not much else, all boards we have tried put out a good calibration signal - even if they were putting out a bad cal signal a minute ago with the original software.

Anyone have any ideas what we can try to get around this problem? Thanks for any advice here!

[JOwen.1]

I got excited when I read your post and tried similar value crystals and cap's. Unfortunately, it just lowered the RTC frequency on three boards to 0.8xxx Hz - WAY off 1.000000 Hz.

Thank you for posting you results, just wish it worked better for me!

[waclawek.jan]

There's no way a crystal oscillator to run 20% off its nominal frequency - at that point, it was not a crystal oscillator anymore.

Have we already discussed your ground and VDD arrangement/supply/routing/decoupling?

JW

[JOwen.1]

I've followed the ST guidelines for crystal layout including guard traces around the crystal tied to ground. It is a 6 layer board with ground right below the top layer. Picture attached. This RTC just does not work consistently from CPU to CPU.

[waclawek.jan]

It appears you have a ground layer. How does it look like? Is it uninterrupted between the vias from C157/C158 and the GND pin closest to the xtal pins? (note the common via in franck23 ' s post - a nice way to reduce unwanted parasitics, although not critical).

What is the power supply arrangement? What is the power supply voltage? Is VDD/VSS as measured at the closest pins to the crystal pins rock stable?

How is VBAT connected exactly?

JW

[JOwen.1]

The ground plane is cut out under the crystal per the ST app notes, though that did not seem to help anything (was a solid ground plane in earlier versions). Ground layer turned on in the attachment so you can see what I mean. Power supply is 3.3V and looks clean to me. I have a 2.2uF and a 0.01 uF cap on VBATT by the CPU. VBATT comes from a 2032 battery through a diode and 1K resistor. This is really a moot point at this time, I've already added an external RTC to get a reliable clock. I do appreciate the feedback, though.

[Andrew Lohmann]

Those unconnected guard track ends are not ideal but I don't see a problem with them and they may be a good thing. A solid 0V plane under the crystal and the 0V the first inner layer below it should have been okay comparing with what Franck has done. But just an aperture in the power planes beneath the crystal's own plane is often recommended, but I do not think you need to do that. The significant thing is that I do not see an 0V connection to the crystal.

That does not give you anything clearer.

[franck23]

Hi JOwen,

Yeah, 20% error seems crazy. I am even surprised that your oscillator starts.

Maybe you want to check the software side:

hrtc.Init.AsynchPrediv = 127;
hrtc.Init.SynchPrediv = 255;

[JOwen.1]

Ha! I know! But it is the same software that gave about 1 Hz with a 6 pF cap and 1.5 pf load capacitors.

[JOwen.1]

Andrew, if you mean a 0V connection to the crystal case, this is a surface mount crystal with no case connection.

[Andrew Lohmann]

Thanks for the explanation on the smt part.

[waclawek.jan]

> This is really a moot point at this time, I've already added an external RTC to get a reliable clock.

But you are still annoyed by the problem, aren't you? Otherwise you wouldn't perform that experiment today morning... ;)

Hardware appears to be as good as it gets at this point. The "repair by changing chip" still sounds strange. This is a new info, though:

> I have a 2.2uF and a 0.01 uF cap on VBATT by the CPU. VBATT comes from a 2032 battery through a diode and 1K resistor.

"Changing chip" may have the "side effect" of resetting the backup domain, so the question is, whether you attempted to reset the backup domain on the "faulty" boards/chips beforehand, and/or checked/read out the related RCC and RTC registers' content. The idea is, that there are interconnections in the backup domain registers, e.g. after [inadvertently] setting incorrect LSE drive or RTC clock source, there may be some reason that it can't be undone/changed until a backup domain reset.

JW

[bb1]

I just noticed something in one of the app notes that could support this theory. Apparently changing the drive level requires stopping the LSE starting with Rev V, so tests of different drive levels will be invalid if they do not involve explicitly stopping the LSE, resetting the backup domain, or removing the battery.

The errata does not mention this and the reference manual says that you can change it on the fly (at least in some limited cases).

RM0433: "The driving capability can be changed dynamically from high drive to medium high drive, and then to medium low drive."

AN5312: "On RevV the driving capability cannot be changed when the LSE oscillator is ON."

The CubeMX generated initialization code just sets the drive level at every startup, so it will be ineffective if a prior program already started the LSE. It may not even be possible to reliably determine the current drive level if the write updates the register but not the actual drive level. (Update: Tried it; fortunately the write does not change the register in that case)

FWIW, my initial tests on one board did not reveal any problems with STM32H753ZI, medium-high drive, either ECS-.327-7-12R-TR or CM8V-T1A-32.768KHZ-7PF-20PPM-TA-QC, and 4.7 pF caps.