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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[JOwen.1]

Here is a summary of what I found working with the H7 RTC 32KHz oscillator before I put this chapter of my life behind me.

Here is my setup:

1. I'm using the same 6 pf load cap crystal as ST uses on their eval boards (NX3215SA-32.768KHZ-EXS00A-MU00529).
2. I'm using the same load capacitors as the eval board (1.5 pF).
3. I'm using high drive for the oscillator, but the drive strength does not seem to matter with my problems.
4. I use the 1 Hz calibrate output signal to check the RTC accuracy.

Here is what I have learned:

1. The data sheet does not state this very clearly, but don't try to use a 12 pF crystal with the H7 - even though they list a few 12 pF crystals in application note AN2867 as good to use with the H7. A lot of boards won't start oscillating with a 12 pF crystal.
2. Even with "good" boards, the RTC calibrate frequency jumps around (with calibration turned off) by about 0.0001 Hz, making it difficult to know the exact calibration value to use.
3. About 10% of boards will oscillate so far off 32.768 KHz that they cannot be calibrated.
4. About 2% of board's RTC frequencies will be very unstable, having RTC frequencies that jump all around when monitoring the calibrate out signal. Replacing the CPU will normally fix them, but this is an expensive fix!
5. Don't expect the calibrate out signal to work at 512 Hz, it only works at 1 Hz out.
6. Take what I learned, avoid the hassle, and just use an external RTC when using the H7 family.

[Garnett.Robert]

I agree with you. That people have scrupulously cleaned the board to get the clock working is crazy stuff. Unless you seal a board hermetically in its working environment it is going to get "dirty" thus potentially stopping the clock.

I used a H7 for use as a precision mains power voltage and current monitor, luckily I used a GPS module to generate the clock and various references. The GPS basically sets the H7 RTC Time/Date registers and syncs it with a 1 Hz GSPDO.

I had the same problem with calibration that you did. I also found that when the board is powered up the clock sort of works's but run it on VBat and it loses time chronically like seconds in a few minutes. I suspect that this is due to drop-outs and restarts, but without the CPU running it's difficult to know. Putting a scope probe on the xtal doesn't seem a valid measurement with such a dodgy clock.

I also couldn't make any sense out of the 512 Hz cal signal; it seemed to be running at 434 Hz. Weird! I didn't bother with the 1Hz signal. I kind of gave up at this point.

I wish ST would address the problem and fix it. Adding a decent external clock is a pain.

[waclawek.jan]

> That people have scrupulously cleaned the board to get the clock working is crazy stuff.

The "watch" oscillator is an ultralow-consumption analog circuit, so you have to treat it as such. It's easy to create a robust high-power oscillator (well, the crystal would need to be built to withstand that, too; possible but there's no reason to do that); except that you wouldn't be able to run your RTC from a coin cell for months, and this is not what most users want.

In fact, you *CAN* run the RTC out of HSE on most of the STM32 families (I don't use the 'H7). And HSE, while still analog and still needs relatively careful treatment, is usually more robust than LSE; but logically there are no low-power facilities available for that.

> Putting a scope probe on the xtal doesn't seem a valid measurement with such a dodgy clock.

That is of course related. Typical passive oscilloscope probes represent typically 1MOhm and a couple of pF (or using 1:10 probe representing maybe around 10MOhm but few tens of pF), which is WAY too high a load to the typical LSE circuitry. There are active probes around which you can use to probe such circuts, but they are usually at the higher price range; and still it's a nontrivial thing to do without influencing the given circuit too much.

> without the CPU running it's difficult to know

You can output LSE to MCO in some families; again, I don't know about the availability of this on 'H7. Not in VBAT mode, though; but maybe in some low-power modes it may be available; check the RM.

> Unless you seal a board hermetically in its working environment it is going to get "dirty" thus potentially stopping the clock.

If you are concerned about [conductive] "dirt" (or, for that matter, humidity condensation or other environmental impact), consider using some form of conformal coating.

> I also couldn't make any sense out of the 512 Hz cal signal; it seemed to be running at 434 Hz.

I don't say the 'H7 are flawless, but I find it unlikely it wouldn't work at all.

> I also had trouble with a Discovery STM32H7B3I-DK.

That's disappointing indeed as those boards are supposed to be "known good", and I'd love to hear from ST in this regard (but won't hold my breath, ST almost never comments here on more complex technical issues); but again it's an overly complex board with too many sources for disturbance. Try maybe with a simple program with nothing else running (mainly no LCD and external memory) but the RTC and some suitable output pins. Or, if you have one at hand, try with a simpler Nucleo board.

> Even with "good" boards, the RTC calibrate frequency jumps around (with calibration turned off) by about 0.0001 Hz, making it difficult to know the exact calibration value to use.

The 'H7 is primarily a massive digital circuit built on a 28nm technology; I believe the analog performance on such an IC is a matter of heavy tradeoffs. Even with perfect 32kHz oscillations, I would expect variation in the input comparator threshold resulting in jitter in the order of say quarter of the 32kHz oscillation period, i.e. around 8us. That would exhibit itself as 8ppm jitter at 1Hz, whereas your finding is an order of magnitude higher, around 100ppm. Still assuming perfect 32kHz oscillation, maybe this is the contribution of the asynchronous part of the divider. I understand your frustration, but would you be willing to experiment further, maybe you could try to measure over a longer period.

JW

[franck23]

Hi,

I had issues with the RTC which would lose around 1sec per minute when other peripherals were running.

In my case, lowering the oscillator capacitors did the trick (clearly, I had it easy compared to others!)

I am posting my setup so that it can be re-used.

Here is the board setup:

• STM32H743 Rev V, LQFP 176, 480MHz
• 32.768kHz oscillator: Abracon - AB38T-32.768KHZ, 20ppm, 12.5pF
• OSC32 capaciors: 3.3pF, no series resistors
• SDRAM, 32bits bus, 120MHz
• TFT LCD 24bits, 51.2MHz
• QSPI, 240MHz

4 Layer board, 1.6mm:

• L1: Top Layer (red),
• L2: Ground plane (not shown)
• L3: Power plane (not shown)
• L4: Bottom Layer

 

As you can see in the pictures above, the SDRAM and the LCD tracks are all around the osc32 signals. However, most of them are on a different layer and separated by the ground plane (not visible in the pictures).

I do not have guard around the oscillator and there is no copper flooding under it.

The oscillator tracks are 20mm long.

The ground and power layers are not split under the oscillator signals.

Oscillator capacitors are connected by a common via to the ground plane.

There is no ground separation with the other devices, but there is appropriate decoupling located less than 3mm of each power pin.

I hope it can help!

[Andrew Lohmann]

If I understand, the oscillator comes out as a pair, goes below then comes back to the top, then the pair terminates at the capacitors then tracks a little more to the crystal. No doubt adding PCB capacitance, which you adjust for by reducing the values of the capacitors. I would have tried to keep everything closer to the uC pins (or at least the capacitors closer) but that is interesting you show that the oscillator is much more tolerant than any manufacture would admit to. Also that you use the port pins on either side of the oscillator pins rather than connect them to 0V to form a guard ring.

I thought microcontrollers were more tolerant as you have proven. Thanks for the tip. I rarely get work so I write web or blog pages on electronics so I like to use your pictures on my blog, not sure where just now but to show how robust the oscillator is.

https://blog.andrew-lohmann.me.uk/2020/09/electronics-design-project-bicycle.html

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