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!

[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;

[franck23]

Hi Andrew,

Sure I would have preferred the oscillator closer to the pins (was not possible in this case). On this layout, the length of the track between the oscillator and MCU pins is 20mm.

But remember that it is a 32kHz oscillator, so not as critical as a 20Mhz oscillator.

And yes, you can use those pictures on your blog without restriction.

[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.

[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

[Andrew Lohmann]

Thanks for the explanation on the smt part.

[JOwen.1]

I have not tried to reset the backup domain registers directly. Our code probably sets them up on boot. Except for drive strength, I was not aware of any other register settings that would affect the basic frequency of the RTC. By the way, I tried different drive settings. Different drive strength settings caused a slight shift in frequency, but over all there was not much difference or improvement to the problems I've been seeing.

[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.