STM32H7xx RTC accuracy problems

JOwen.1 · ‎2020-06-17

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:

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

waclawek.jan · ‎2020-06-30

I'm then not sure if the problem would be crystal and capacitors choice, why would changing the mcu help.

JW

JOwen.1 · ‎2020-07-01

Good question. We have had other problems with the new V version of the H743, namely frequent failures transferring data with the USB port that we did not see with the older Y version of the CPU. The new part's USB port appears to be much more sensitive to noise - maybe there is a similar issue with the oscillator. I don't remember seeing RTC issues with the older Y CPU's, but I can't say for sure.

JOwen.1 · ‎2020-11-20

We updated our artwork to give the 32KHz crystal it's own ground plane and added guard traces around the crystal, but that did not seem to improve the RTC performance. I don't have a large sample group for this build, but the initial tests are not looking good. I see that the frequency is jumping around on some of these new boards with calibration turned off and the clock output turned on. Right now, the best option is to use an external RTC device and forget about using the internal RTC.

If anyone can recommend RTC crystals/cap combinations that work well with the STM32H7xx parts, I would love to try them.

Andrew Lohmann · ‎2020-12-13

In the past and on other makes of integrated circuit I have used pins either side as 0V plain, 0V plain all around and beneath the crystal and plenty of vias coupling the 0Vs at many points. This is what most manufacturers recommend they also used to say have no track beneath, which I usually do.

It seems that stm32 is much less demanding but have any of you responding to this question found that?

For example would you use the pins either side of the crystal but add NPO/cog capacitor s eg 1nF? Or simply just use those pins?

I am interested in your comments myself.

JOwen.1 · ‎2021-03-22

I've modified the PCB to follow the guidelines recommended in St's application note (cut out ground plane, no traces under crystal, grounded guard traces around crystal traces), but it did not make the RTC oscillator work any better than before. I'm punting on the internal RTC and am adding an external RTC IC (PCF85063). So far the external RTC is working great.

Andrew Lohmann · ‎2021-03-22

It sound like your PCB is more noisy generally. I would not recommend separate ground planes they can ring but you may be able to mitigate that by putting a bead inductor in series with 0V crystal common point. that is a low Q inductor.

waclawek.jan · ‎2021-03-22

I would say the same, would not there be the fact that the "faulty" boards were "repaired" by changing the mcu.

Excessive noise would be also likely to throw off the extenal RTC too - I understand that this is not that good a test given it may be layout/3D arrangement/etc. dependent.

JW

JOwen.1 · ‎2021-03-26

One more interesting note - it does not appear to be related to general noise on the board because I can stop the CPU with the debugger (which stops all signal activity on the board) and it has no effect on boards with a jittery RTC frequency. My personal opinion is that the RTC oscillator is marginal on this part and I'm worried boards that worked in factory test might start to get jittery later on in a customer's location. We are switching to an external RTC as soon as we can.

That was a good suggestion about adding a ferrite, had not thought of that. But I don't think in this case it will make much difference.

waclawek.jan · ‎2021-03-26

Nice try.

Debugger won't stop the mcu itself, nor its high-frequency clocks (including the PLLs) and buses. As an experiment, you may want to write a simple trivial program which does absolutely nothing, not even call the startup code - the RTC will be running from being set previously - or alternatively, try to place a breakpoint at the startup code's first line and reset using debugger.

There's then still the communication with the debugger itself, so you may want to write a simple trivial program to do nothing, and run it without the debugger connected.

You may also want to try it on a "known good" board such as Nucleo or Disco.

JW

Garnett.Robert · ‎2021-04-01

Hi,

I have had trouble with the H7 LSE.

I had problems with the oscillator starting on a custom board. Increasing the LSE drive to high fixed this. It wasn't a ball grid chip so I was able to get the xtal and caps right on the chip. I used one of the 32 k xtals recommended.

I also had trouble with a Discovery STM32H7B3I-DK. The oscillator kept dropping out after running the board for an hour or so. Increasing the LSE drive stopped the drop-out, but there was a lot of jitter on the clock (MC01) and it was running slow. The 24 MHz clock was as steady as the proverbial rock and better than 1 PPM accuracy, measured against a GPSDO.

I cannot understand why layout for the LSE xtal should be so critical as the frequency is only 32.7 kHz.

I reckon the topology of the oscillator being used is the problem not the xtal and external circuitry.

The 32.7 k clock oscillator is ubiquitous and doesn't seem to be a problem for other manufacturers.

It seems to be spoiling a very good ship for a halp'th of tar.

I will be using an external clock oscillator in my future designs as I don't have much faith in the H7 LSE.