STM32CubeWL
STM32CubeWL copied to clipboard
STMicroelectronics
Clock drift: increasing approx. 10 second at each 24 hours
Hello, we are using release 1.0.0, We have configured RTC as below using clock source as LSE. But at every 24 hours time is increased with ~10 seconds.
Example : Suppose at starting time if RTC time is 00 seconds. After 1st 24 hours getting time 86410 approx. After 2nd 24 hours getting time 172820 approx.
`void MX_RTC_Init(void) { RTC_AlarmTypeDef sAlarm = {0};
/** Initialize RTC Only */ hrtc.Instance = RTC; hrtc.Init.AsynchPrediv = RTC_PREDIV_A; hrtc.Init.OutPut = RTC_OUTPUT_DISABLE; hrtc.Init.OutPutRemap = RTC_OUTPUT_REMAP_NONE; hrtc.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH; hrtc.Init.OutPutType = RTC_OUTPUT_TYPE_OPENDRAIN; hrtc.Init.OutPutPullUp = RTC_OUTPUT_PULLUP_NONE; hrtc.Init.BinMode = RTC_BINARY_ONLY;
if((RCC->BDCR & RCC_BDCR_RTCEN) == 0) //Init only on hard reset case { if (HAL_RTC_Init(&hrtc) != HAL_OK) { Error_Handler(); }
} else { HAL_PWR_EnableBkUpAccess();
/* RTC clock enable */
__HAL_RCC_RTC_ENABLE();
__HAL_RCC_RTCAPB_CLK_ENABLE();
/* RTC interrupt Init */
HAL_NVIC_SetPriority(TAMP_STAMP_LSECSS_SSRU_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(TAMP_STAMP_LSECSS_SSRU_IRQn);
HAL_NVIC_SetPriority(RTC_Alarm_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(RTC_Alarm_IRQn);
}
/** Initialize RTC and set the Time and Date / if (HAL_RTCEx_SetSSRU_IT(&hrtc) != HAL_OK) { Error_Handler(); } /* Enable the Alarm A */ sAlarm.BinaryAutoClr = RTC_ALARMSUBSECONDBIN_AUTOCLR_NO; sAlarm.AlarmTime.SubSeconds = 0x0; sAlarm.AlarmMask = RTC_ALARMMASK_NONE; sAlarm.AlarmSubSecondMask = RTC_ALARMSUBSECONDBINMASK_NONE; sAlarm.Alarm = RTC_ALARM_A; if (HAL_RTC_SetAlarm_IT(&hrtc, &sAlarm, RTC_FORMAT_BCD) != HAL_OK) { Error_Handler(); }
} `
Hello @PG430
Please try to adjust the defind LSE_VALUE in stm32wbxx_hal_conf.h file according to your LSE oscillator used on the board. #if !defined (LSE_VALUE) #define LSE_VALUE (32768UL) /!< Value of the External oscillator in Hz/ #endif /* LSE_VALUE */
With Regards KORKAD
I was experiencing the same thing and I did some measurements. The H7 issue suggested this was due to repeat clock initialization, so I setup an experiment:
- 2x STM32WLE5 clients (one outdoors, one indoors) on battery power. These transmit their RTC value every 15 minutes, then go into shutdown. The RTC is initialized upon exit from shutdown, if the calendar is not already setup (per the linked H7 issue).
- 1x STM32WLE5 server, always powered, RTC initialization performed once. This is connected to an Ethernet chip, and it synchronizes the RTC with my NTP server every 3 hours.
The y-axis is the difference between the server RTC and client RTC, the slopes between the 3h jumps represent the drift between clients and server, and the 3h jump represents the drift between the server and my NTP.
- Clients in shutdown loose ~325ms every 3 hours as referenced to the always-on server
- The server looses ~1,894ms every 3 hours as referenced to my NTP
The linked H7 and G0 issue indicates this is a code bug with repeat calls to HAL_RTC_Init, but I think there is more going on here given that significant drift is experienced with an always-on STM32WL.
I did some more digging on my issue, turns out the LSE frequency is really far off (32.775 kHz, 232 ppm) on the seeed LoRa-E5 modules I am using.
@newAM
I did some more digging on my issue, turns out the LSE frequency is really far off (32.775 kHz, 232 ppm) on the seeed LoRa-E5 modules I am using.
I have run into this too with LoRa-E5. I have calibrated the RTC using the internal timer that was clocked by the module's TCXO and the drift seems to be fixed. I cannot validate this precisely because the module does not have a calibrated RTC output connected to the pin, but I am sending messages to TTN each hour and the timing is precise, so it is ok for me now.
The calibration process is described here. An example implementation can be found here. My measurements are here.
Hi @PG430, @newAM, and @darkmoon32,
From a software point of view, the fix has been published that prevents going into RTC initialization after system or software reset in case RTC is already initialized. This is to avoid freezing the calendar's time and date during the initialization procedure. Here is the link to the check added.
The fix has been published in the frame of version 1.3.0 of the STM32CubeWL firmware. Further calibration of RTC's accuracy may be rather related to the clock signals used (e.g., LSI or LSE clocks). You can also have a look to this comment for further information.
Please allow me to close this issue. Thank you for your comprehension.
With regards,