F767 Nucleo RTC drift

[macgeorgio]

Posted on January 15, 2017 at 09:01

Hello,

I have been using the RTC of the Nucleo 144 F767 board with the onboard 32768kHz oscillator and I noticed that there is a large drift (~2 minute lag per day or ~1570ppm).

Based on the datasheet, the crystal drift is 200ppm. Moreover, the calibration registers can compensate for �488ppm, so I have to finetune the clock using the synchronous and asynchronous prescalers.

I am wondering if I haven't initialized the registers correctly (key registers shown below) or if someone else has noticed a similar clock drift on Nucleo boards.

Thanks,

George

System Init

SCB_EnableICache();

SCB_EnableDCache();

__HAL_RCC_PWR_CLK_ENABLE();

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE|RCC_OSCILLATORTYPE_LSE;

RCC_OscInitStruct.HSEState = RCC_HSE_ON;

RCC_OscInitStruct.HSIState = RCC_HSI_OFF;

RCC_OscInitStruct.LSEState = RCC_LSE_ON;

RCC_OscInitStruct.LSIState = RCC_LSI_OFF;

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

RCC_OscInitStruct.PLL.PLLM = 8;

RCC_OscInitStruct.PLL.PLLN = 432;

RCC_OscInitStruct.PLL.PLLP = 2;

RCC_OscInitStruct.PLL.PLLQ = 2;

HAL_RCC_OscConfig(&RCC_OscInitStruct);

RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;

RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;

RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_7);

HAL_PWREx_EnableOverDrive();

PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_RTC|RCC_PERIPHCLK_USART3;

PeriphClkInitStruct.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;

PeriphClkInitStruct.Usart3ClockSelection = RCC_USART3CLKSOURCE_PCLK1;

HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);

RTC Prescalers

RTCHandle.Init.AsynchPrediv = 127;

RTCHandle.Init.SynchPrediv = 255;

#nucleo-f767zi #f767-rtc

[Imen.D]

Posted on January 17, 2017 at 16:36

Hello

Christidis.George

‌,

You can perform a digital smooth calibration to compensate the RTC clock deviation

for the inaccuracy of crystal oscillators. This is mentioned in the

application note

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/71/b8/5f/6a/8e/d5/45/0a/DM00226326/files/DM00226pdf/jcr:content/translations/en.DM00226pdf

in the 'Digital smooth calibration' section.

Also, you may review the

http://www.st.com/content/ccc/resource/technical/document/application_note/c6/eb/5e/11/e3/69/43/eb/CD002216pdf/files/CD002216pdf/jcr:content/translations/en.CD002216pdf

and RTC chapter in your

http://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/96/8b/0d/ec/16/22/43/71/DM00224583/files/DM002245pdf/jcr:content/translations/en.DM002245pdf

for more clarification.

Hope this helps you.

Regards

Imen

[Andrei Chichak]

Posted on January 17, 2017 at 21:01

I had this problem once, it turned out that the EE didn't put the proper capacitors for the oscillator. 

Different crystals specify the capacitor/resistors that they need to get their designed precision. Make sure the implementation matches the design.

A

[macgeorgio]

Posted on January 17, 2017 at 20:42

Thanks for your response. The digital calibration does not apply for this case, since, as I wrote above it can manage a maximum drift of ±448ppm and I am observing a drift of 1570ppm. That's why I am obligated to use the synchronous and asynchronous prescalers (RTC->PRER).

Concerning the documentation you have indicated, since I am using a Nucleo board, board layout shouldn't be an issue, although based on the schematic, the capacitance is a bit different than the recommended one (maybe to compensate for the track capacitance as well).

Moreover, since the RTC is indeed operating, the rest of the initialization seems correct (except maybe the setup of the registers that select RTC timing). So my question was to inquire if someone else has seen similar drifts on the specific board.

Thanks,

George

[T J]

Posted on January 17, 2017 at 22:30

Clocks have been perfected over hundreds of years.

The clients are really expecting an accurate time.

Can you update from the web periodically ?

Otherwise a stand alone RTC is necessary... Specified @ Max 2Minutes deviation per Year,

DS3231 IIC with internal Temperature Compensated Crystal without battery backed ram,

DS3232 IIC with internal Temperature Compensated Crystal with 236bytes ram,

DS3234 SPI with internal Temperature Compensated Crystal with 256bytes ram,

or less accurate DS3232M (4minutes per year drift) without crystal

[john doe]

Posted on January 18, 2017 at 12:58

Given the ds323x series has many of the same features as the stm32 rtc, how would you use the ds323x?

Would you set your stm32 rtc and periodically compare it to the ds323x, or would you turn off the stm32 rtc and use just the ds323x?

[T J]

Posted on January 18, 2017 at 13:28

Hi,

I would update every hour.. if you are concerned, maybe every minute...

I actually, just use the DS3232SN product, I don't use the processor RTC at all.

basically only read it when I need to timestamp.

[Steve Hageman]

Posted on January 19, 2017 at 16:26

Hi George - I have had many problems from these 32kHz clocks over the years due to humidity - because of the very high impedance's involved they are very, very sensitive to even 'normal' atmospheric humidity.

One thing that I see on a lot of pre-made computer boards is a coating of 'RTV' over the crystal oscillator portion of the circuit to keep the humidity out.

One way to test if humidity is the problem is to put the board next to a heat lamp (or light bulb, etc) and heat it to 10 to 20 Deg C over ambient and to check if the problem goes away. Heating a board like this will drive the humidity right out of it.

If this heating fixes the problem then you know it is humidity.

Hope this helps.