RTC timing is slower up to 10 seconds every minute.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-24 3:08 AM
Hello,
I run with eval board RTC_timestamp example:
en.stm32cubeh7\STM32Cube_FW_H7_V1.3.0\Projects\STM32H743I_EVAL\Examples\RTC\RTC_TimeStamp\EWARM
Surprisingly, there is a shift delay of ~9 to 10 seconds (!) every 60 seconds.
I tested it as following:
use stop watcher clock reference for measurement
started the example and put a breakpoints just after HAL_RTC_GetDate
static void RTC_CalendarShow(void)
{
RTC_DateTypeDef sdatestructureget;
RTC_TimeTypeDef stimestructureget;
/* Get the RTC current Time */
HAL_RTC_GetTime(&RtcHandle, &stimestructureget, RTC_FORMAT_BIN);
/* Get the RTC current Date */
HAL_RTC_GetDate(&RtcHandle, &sdatestructureget, RTC_FORMAT_BIN);
/* Display time Format : hh:mm:ss */
--> nreakpoimt here !!! sprintf((char*)aShowTime,"%.2d:%.2d:%.2d", stimestructureget.Hours, stimestructureget.Minutes, stimestructureget.Seconds);
I see that diff time between real time and the time from stm32 RTC is 10 seconds .
STM32 RTC time is slower by 10 seconds every 1 minute !
Thank you for any suggestion,
ran
Solved! Go to Solution.
- Labels:
-
RTC
-
STM32Cube MCU Packages
-
STM32H7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-24 3:22 AM
Check the clock source and tolerances. RTC would work ideally with 32.768kHz LSE clock instead of the LSI.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-24 3:22 AM
Check the clock source and tolerances. RTC would work ideally with 32.768kHz LSE clock instead of the LSI.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-24 6:24 AM
Check Prescalers vs clock source, the LSI does not clock at 32.768 KHz, more likely to be 32 KHz. This wouldn't account for such a gross error.
Don't breakpoint the code. The debugger might stop clocks or distort time via DBGMCU settings.
Use the 1ms SysTick against a crystal source to count off 1000 ms
Or use a GPS 1PPS to generate an interrupt
You might also be able to route LSI or LSE out via MCO pins, or against an internal timer.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-26 5:58 AM
Thanks, changing to LSE fixed the issue!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-12-24 10:06 AM
I had the same problem with a STM32L010 and an IQD LFXTAL009678 crystal.
After debugging for several hours I finally found out that the configured driver
strength for the OSC_Out pin was too low. After increasing it from "low" to
"medium high" all problems have vanished. ST also mentions in AN2867 that
especially high load capacitance (such as 12.5 pF) crystals should be driven
with higher strength.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-12-24 10:58 AM
Early model STM32 only worked at all with 6-7 pF watch crystals, where as 9 or 12pF's were quite prevalent.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-12-24 11:00 AM
Yes, in AN2967 are also tables for combinations of STM32 product lines and valid crystals.
