cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 RTC loses one second after each reset

coppercrimp
Associate III
Posted on May 23, 2017 at 07:46

I have a custom board based on the STM32F407 device. The board is running well except for one nagging detail: the RTC loses one second each time I power the board on/off

My device uses a low frequency external crystal and a backup coincell battery. The crystal is the CM7V-T1A 32.768kHz from Micro Crystal and it runs fine and keeps accurate time from either the coincell or main battery power. But again, the RTC looses approximately 1 second every time the board is powered on from the main external batteries. If the user powers the board on and off ten times (while keeping the backup coincell connected of course), then approximately 10 seconds of time is lost on the RTC.

I see many postings on this forum of people reporting loss of time when coming out of sleep modes. However my problem happens irregardless of whether the processor ever enters sleep mode. I do check the Wakeup Flag and the Standby Flag on power up though. Below is the first lines of code from my main() function:

int main(void)

{

HAL_Init();

/* Configure the system clock */

SystemClock_Config_HighSpeed();

/* Initialize all configured peripherals */

MX_GPIO_Init();

CheckFlashDefaults();

MX_DMA_Init();

MX_I2C1_Init();

MX_SDIO_SD_Init();

StatusLED_ConfigI2C(&hi2c1);

if(__HAL_PWR_GET_FLAG(PWR_FLAG_WU) != RESET)

{

      __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU);

}

/* Check the status of standby flag SB*/

if (__HAL_PWR_GET_FLAG(PWR_FLAG_SB) == RESET)

{

      RTC_Init();

}

else

{

      /*Resuming from standby routine */

      __HAL_PWR_CLEAR_FLAG(PWR_FLAG_SB);

}

And here is the code that initializes the RTC:

void RTC_Init(void)

{

   RTC_TimeTypeDef sTime;

   RTC_DateTypeDef sDate;

   /**Initialize RTC and set the Time and Date

   */

   hrtc.Instance = RTC;

   hrtc.Init.HourFormat = RTC_HOURFORMAT_24;

   hrtc.Init.AsynchPrediv = 127;

   hrtc.Init.SynchPrediv = 255;

   hrtc.Init.OutPut = RTC_OUTPUT_DISABLE;

   hrtc.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;

   hrtc.Init.OutPutType = RTC_OUTPUT_TYPE_OPENDRAIN;

   HAL_RTC_Init(&hrtc);

   /* Read the Back Up Register 0 Data */

   if(HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR0) != 0x32F2)

   {

      /* Configure RTC Calendar */

      sTime.Hours = 4;

      sTime.Minutes = 0;

      sTime.Seconds = 0;

      sTime.SubSeconds = 0;

      sTime.TimeFormat = RTC_HOURFORMAT12_AM;

      sTime.DayLightSaving = RTC_DAYLIGHTSAVING_NONE;

      sTime.StoreOperation = RTC_STOREOPERATION_RESET;

      HAL_RTC_SetTime(&hrtc, &sTime, FORMAT_BCD);

      sDate.WeekDay = RTC_WEEKDAY_MONDAY;

      sDate.Month = RTC_MONTH_JANUARY;

      sDate.Date = 1;

      sDate.Year = 0;

      HAL_RTC_SetDate(&hrtc, &sDate, FORMAT_BCD);

      /*♯♯-3- Writes a data in a RTC Backup data Register0 ♯♯♯♯♯♯♯♯♯♯♯♯♯♯♯♯♯♯♯♯♯*/

      HAL_RTCEx_BKUPWrite(&hrtc,RTC_BKP_DR0,0x32F2);

   }

}

#stm32f4 #rtc
35 REPLIES 35
Posted on December 06, 2017 at 15:08

Checking, performing a new initialization of the clock in case of an error:

if (! ((RCC->BDCR & RCC_BDCR_LSERDY) /// hour quartz worked before

&&(((RCC->BDCR) & RCC_BDCR_RTCSEL ) == RCC_BDCR_RTCSEL_0) /// switch on external clock quartz

&&((RCC->BDCR) & RCC_BDCR_RTCEN)) )/// the clock is already working

{

//Your code for starting the clock and calendar

}

Posted on December 07, 2017 at 00:50

I'm seeing a loss, but not a full second, and its directly proportional to how long the chip is held in reset.

WWVB 23:43:00 UTC Day 340 of 2017
WWVB DUT1 +0.2 DST: No Leap year: No Leap second: No
RTC 17:44:01 12/6/2017 Updated from WWVB 
DS3231 17:44:01 12/6/2017 Updated from WWVB
DS3231 Local time: Wednesday, December 6, 2017 5:44:01 pm
Connected to UART Two of STM32L476RG-Nucleo
Built: 17:37:48 Dec 6 2017
RTC 17:44:13 12/6/2017 
DS3231 Local time: Wednesday, December 6, 2017 5:44:13 pm
Connected to UART Two of STM32L476RG-Nucleo
Built: 17:37:48 Dec 6 2017
RTC 17:44:20 12/6/2017 
DS3231 Local time: Wednesday, December 6, 2017 5:44:20 pm
Connected to UART Two of STM32L476RG-Nucleo
Built: 17:37:48 Dec 6 2017
RTC 17:44:27 12/6/2017 
DS3231 Local time: Wednesday, December 6, 2017 5:44:28 pm
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

This is an L476 compared to a DS3231 and both are synchronized to the national time code at the same time. Using the HAL code the STM32CubeMX application generated.

Imen.D
ST Employee
Posted on March 16, 2018 at 15:44

Hello All,

I confirm this issue for HAL RTC and highlighted internally to developer team for fix.

Sorry for such inconvenience.

Best Regards,

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen
MSine
Associate

I solved this problem in the following way:

0690X000006DkvIQAS.png

Czhih.1837
Associate

thanks a lot! This does work.

best Regards,

Albert

Adsou.1
Associate II

Hello Robert, Siddharth,

Actually i also see this exact same issue and was wondering if you guys managed to figure this out. Any pointers would be greatly appreciated.

I work with the STM32f779i on a custom board and use HAL.

Thanks,

Abel

Perhaps because you are using a different series of microcontroller. Other drivers may be used for your series. Try to debug the code step by step in all method implementations. That’s how I fixed this problem myself

Than you. Yes we should not be calling RTC init at every boot up. We have also fixed this. thanks for your reply.

ALABSTM
ST Employee

Hi @Community member​,

We are actively working on this issue. Once a fix is available, we would make it available on GitHub, pending its integration in a new Cube firmware release. We will keep you informed.

With regards, 

ALABSTM
ST Employee

Hi,

I hope  everybody's fine. Just to let you know this issue has been fixed and the fix is available on GitHub here.

The idea is to check whether the RTC needs to be initialized by reading the status of bit RTC_FLAG_INITS.

As the fix is implemented at the HAL RTC driver's level, the user needs no more to handle the point at their application's level.

Do not hesitate should you have any feedback related to this topic.

As for other series whose RTC drivers suffer the same issue (I saw STM32F1 mentioned), the fix should be implemented and published too. Unfortunately, we cannot share a date for the moment. Thank you all for your comprehension.

With regards,

PS: Please note this fix is still to be integrated into a new STM32CubeF4 firmware version.