RTC Time Drift Issue in STM32H743ZIT6

[RahulBaraiya]

We are developing a project using the STM32H743ZIT6 where RTC timekeeping is a critical requirement. During field testing we noticed significant RTC drift on our board. We tested the same hardware three times — each time flashing a different RCC_LSEDRIVE_* setting  to identify which drive level gives the best RTC accuracy. Sharing the full details below test results, firmware, and hardware in case others are facing the same issue.

Quick Results 

We ran a 16-hour test measuring RTC drift on the same STM32H743ZIT6 board, flashed three times with a different RCC_LSEDRIVE_* setting each time."

Drive setting	Drift over ~16 hours	PPM
RCC_LSEDRIVE_LOW	69 seconds	~1161
RCC_LSEDRIVE_HIGH	30 seconds	~519
RCC_LSEDRIVE_MEDIUMHIGH	6 seconds	~101

RCC_LSEDRIVE_MEDIUMHIGH gave the best result by a large margin. RCC_LSEDRIVE_LOW — which is often recommended as the default — gave the worst result on our hardware.

Hardware Details

Crystal

Parameter	Value
MPN	ECS-.327-6-12-TR
Frequency	32.768 kHz
Tolerance	±20 ppm
Load cap	6 pF
ESR	90 kΩ max
Package	2-SMD, No Lead

Load Capacitors

Parameter	Value
MPN	0603C0G6R0C500NT
Value	6 pF
Voltage	50V
Dielectric	C0G (NP0) — zero temperature coefficient, ideal for crystal circuits
Package	0603 MLCC SMD

C0G dielectric is the correct choice here — stable across temperature and voltage. This part of the design is sound.

Schematic

The LSE circuit follows the standard two-cap topology:

• PC14 (OSC32_IN) → 0Ω series resistor R5 → crystal Y1 (ECS-.327-6-12-TR) → 0Ω series resistor R9 → PC15 (OSC32_OUT)
• Load capacitor C7 (6pF) from OSC32_IN pin to GND
• Load capacitor C10 (6pF) from OSC32_OUT pin to GND
• Both capacitors are 6PF 50V COG 0603

Schematic

 

PC14-OSC32_IN  --[R5 0Ω]--+--[C7 6pF]-- GND
                           |
                          [Y1]  ECS-.327-6-12-TR
                           |
PC15-OSC32_OUT --[R9 0Ω]--+--[C10 6pF]-- GND

 

PCB Layout

In the PCB view, the crystal Y1 is placed between the two load capacitors C7 and C10. Series resistors R5 and R9 are placed inline on the OSC32_IN and OSC32_OUT traces respectively.

PCB Layout

RTC Clock Mux (STM32CubeMX)

As shown in the clock configuration:

• Input: LSE at 32.768 kHz
• RTC Clock Mux: LSE selected (not LSI, not HSE/2)
• Output: 32.768 kHz → To RTC
• LSI RC (31–32 kHz) is present as fallback but not selected for RTC

This is the  configuration. LSI would give much worse drift (~1–2%) since it is an internal RC oscillator with no external reference.

 

Rtc clock configuration

Firmware Details

Clock Configuration — SystemClock_Config()

c

void SystemClock_Config(void) {
    RCC_OscInitTypeDef RCC_OscInitStruct = {0};
    RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

    HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
    __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
    while (!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

    /* Configure LSE Drive Capability */
    HAL_PWR_EnableBkUpAccess();
    __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_MEDIUMHIGH); // <-- tested at LOW / HIGH / MEDIUMHIGH

    RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI48
                                     | RCC_OSCILLATORTYPE_HSI
                                     | RCC_OSCILLATORTYPE_HSE
                                     | RCC_OSCILLATORTYPE_LSE;
    RCC_OscInitStruct.HSEState              = RCC_HSE_ON;
    RCC_OscInitStruct.LSEState              = RCC_LSE_ON;
    RCC_OscInitStruct.HSIState              = RCC_HSI_DIV1;
    RCC_OscInitStruct.HSICalibrationValue   = RCC_HSICALIBRATION_DEFAULT;
    RCC_OscInitStruct.HSI48State            = RCC_HSI48_ON;
    RCC_OscInitStruct.PLL.PLLState          = RCC_PLL_ON;
    RCC_OscInitStruct.PLL.PLLSource         = RCC_PLLSOURCE_HSE;
    RCC_OscInitStruct.PLL.PLLM              = 2;
    RCC_OscInitStruct.PLL.PLLN              = 64;
    RCC_OscInitStruct.PLL.PLLP              = 2;
    RCC_OscInitStruct.PLL.PLLQ              = 4;
    RCC_OscInitStruct.PLL.PLLR              = 2;
    RCC_OscInitStruct.PLL.PLLRGE            = RCC_PLL1VCIRANGE_3;
    RCC_OscInitStruct.PLL.PLLVCOSEL         = RCC_PLL1VCOWIDE;
    RCC_OscInitStruct.PLL.PLLFRACN          = 0;
    HAL_RCC_OscConfig(&RCC_OscInitStruct);

    RCC_ClkInitStruct.ClockType      = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK
                                     | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2
                                     | RCC_CLOCKTYPE_D3PCLK1 | RCC_CLOCKTYPE_D1PCLK1;
    RCC_ClkInitStruct.SYSCLKSource   = RCC_SYSCLKSOURCE_PLLCLK;
    RCC_ClkInitStruct.SYSCLKDivider  = RCC_SYSCLK_DIV1;
    RCC_ClkInitStruct.AHBCLKDivider  = RCC_HCLK_DIV2;
    RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;
    RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;
    RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;
    RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;
    HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2);

    HAL_RCC_EnableCSS();
}

Predivider note: AsynchPrediv = 127, SynchPrediv = 255 gives: f_RTC = 32768 / (127+1) / (255+1) = 1 Hz — correct for a 32.768 kHz LSE.

 

Questions :

1. Our hardware uses a 6 pF crystal with 6 pF load caps — but effective CL seen by the crystal includes PCB stray capacitance (typically 1–3 pF per node). Could the mismatch between crystal CL spec and effective board CL be contributing to the higher drift at lower drive levels?

Environment

Parameter	Value
MCU	STM32H7 series
HAL	STM32CubeH7
Crystal	ECS-.327-6-12-TR (32.768 kHz, 6pF)
Load capacitors	0603C0G6R0C500NT (6pF, C0G, 0603)
Series resistors	0Ω (R5, R9)
RTC clock source	LSE (selected in clock mux)
AsynchPrediv	127
SynchPrediv	255
Power supply	LDO (PWR_LDO_SUPPLY)
Voltage scaling	Scale 1
Test duration	~16 hours per measurement

Happy to share more log data or PCB details if useful. Any input from teams who have done long-term RTC accuracy work on STM32H7 is appreciated.

[waclawek.jan]

Start with reading AN2867. There are guidelines there, toghether with layout examples.

The key issue often is the return/ground from the “burden” capacitors - it must be a dedicated track to the VSS pin, i.e. not shared/going through a common ground track or plane; and as short as possible.

Also note, that the load capacitance given as parameter to the crystal is NOT equal to the value of individual capacitors. Again, AN2867 contains the info you need.

Also, consider using an external crystal oscillator.

JW

[Andrew Neil]

consider using an external crystal oscillator

 

Or MEMS oscillator ?

[waclawek.jan]

I wish there be a single unambiguous and widely accepted term for “electronic part which actively outputs a fairly  precise 32.768kHz clock signal, as its sole functionality”.

As even “external oscillator” in light of what “LSE” is abbreviation of, may be confusing.

JW

[mƎALLEm]

and 

 

[AScha.3]

>.. where RTC timekeeping is a critical requirement

So i would choose a temp. compensated clock module, as any crystal will drift with temperature many ppm .

The “standard” for a good RTC is DS3231SN :

• about 0.8 uA on 3V batt.
• 3V3 supply + I2C 
• +/- 2ppm typ. , crystal ...etc all inside package

But if you wanna play with the H743 RTC :

• drive medium or high (i use only high , to get it reliable running)
• have correct load cap; for 6pF crystal: try 8..10pF (depends on stray cap. of your layout)
• try : high drive +  2x 10pF caps
• have no possible “disturbing” signal on adjacent pins; any switching here might disturb the RTC

 

[RahulBaraiya]

 

Thank you for your fast response.
Thank you for the suggestions.

I will check the RTC crystal operation using different load capacitor values in the 8–10 pF range and test the oscillator stability.
I will share the results once the testing is completed.

With greetings,
AScha.3

[MM..1]

Next time show sign in your table, because 

Drive setting	Drift over ~16 hours	PPM
RCC_LSEDRIVE_LOW	69 seconds	~1161
RCC_LSEDRIVE_HIGH	30 seconds	~519
RCC_LSEDRIVE_MEDIUMHIGH	6 seconds	~101

seems absurd.

[STOne-32]

Dear ​@RahulBaraiya ,

The comment here from ​@MM..1 is key ! You need to know if the drift is positive or negative each time And then go step by step . To start first by physics on the Crystal oscillation  if running slower or faster than nominal (+/- 50ppm) .

if running faster that means your CL1=CL2 should be increased from 6pF to 8 or 10pF and try again .

the pullability of a crystal of CL=6pF is high versus 9pF or 12.5pF ( best in class for accuracy but higher consumption) .

Drive level on LSE is indeed to allow different options based on your crystal Usage  and is important for start-up condition ton have right margin to start-up .

 

Regards,

STOne-32

 

[mbarg.1]

You are trying to get something the device is not fit.

Internal capacitances add to crystal precision and change according to temperature.

Take one eval board - any STM32xxxx product - move from ambient to hotter or cooler and you drift seconds or even minutes per day.

Obvioulsy, if you use external TCXO you can get several orders of magnitude better stability, but not on long time periods.

As you are using H7xx, you have network connection, and you can use RTC calibration register to match network reference in a closed loop - same if you have some gps with pps or any freq.

I usually get precision < 5/256 s adjusting internal trim once every hour or less according to offset - for my iot is enough; you can get even better reasult if required.

[AScha.3]

 

• Did you try 9..10 pF caps ?

> Is it realistic to achieve 0 seconds drift using the STM32H743 RTC with an external 32.768 kHz crystal?

No, never.

 

> suggestions

• use a TCO , as i showed you one.

> experiences

I made a clock with a 32.768 kHz crystal and cheap DS1302   clock chip, now after about one year, its 2 min ahead, so about 3.8 ppm too fast; i have programmed a compensation, in +/- 1 ppm steps, so i have to adjust a bit.

But now summer, ambient some degree higher, so it will run anyway slower...maybe i adjust - 3ppm, and see end of year, what comes out. (Because if +5° in summer, it will be about - 1 ppm slower , by temperature.)

But -- you have to check and correct individually for every crystal !  So you get busy for some time… :)

[Andrew Neil]

Network time sync has already been mentioned.

But let’s not forget the old-school trick of using the AC mains frequency - that has extremely good long-term stability ...

[mbarg.1]

You made me happy - I had a flashback to 60 years ago when I made a digital clock using nixies driven by sn74141 using mains as clock -- and sold one to my mother !

mike