Cannot set time with HAL_RTC_SetTime on L412KB (Nucleo32) after init.

[Legacy member]

I seem to be unable to set the time more than once after reset. Here is a way to reproduce my problem:

1. Create a new CubeMX project with the RTC enabled
2. Edit the MSP init function the following way:
3. ...After the time and date are set by MSP init
4. ...change the hour in the sTime structure, e.g. sTime.Hours = 0x09;
5. ...and then issue HAL_RTC_SetTime(&hrtc, &sTime, RTC_FORMAT_BCD);
6. ...and then issue HAL_RTC_GetTime(&hrtc, &sTime, RTC_FORMAT_BCD);
7. run the code in the debugger and break in the new readTime call from step 6
8. note that the value of hour has not changed

Or insert this code in your main() function:

/* USER CODE BEGIN 2 */
  if (1) {
    RTC_TimeTypeDef tm;
    HAL_RTC_GetTime(&hrtc, &tm, RTC_FORMAT_BCD);
    tm.Hours = 0x06; /* assuming you initialized to something other than 6 */
    HAL_RTC_SetTime(&hrtc, &tm, RTC_FORMAT_BCD);
    HAL_RTC_GetTime(&hrtc, &tm, RTC_FORMAT_BCD); /* tm.Hours does not change to 6 */
  }
  /* USER CODE END 2 */

Reading the reference manual, the HAL already issues the CR unlock bytes. I've read some posts about writing the RTC_BKP_DR1 with 0x32f2, but that also does not help (and is not mentioned in the reference manual).

Seems like I'm missing something obvious?

Thanks.

[Legacy member · Accepted solution]

I found this on some spanish website for the F439xx HAL, and it fixed the problem:

• You must call HAL_RTC_GetDate() after HAL_RTC_GetTime() to unlock the values in the higher-order calendar shadow registers to ensure consistency between the time and date values. Reading RTC current time locks the values in calendar shadow registers until Current date is read.

By adding HAL_RTC_GetDate immediately after the GetTime on line 4 (above), the code works.

Unfortunately, I couldn't find this useful tidbit in the 412KB reference manual.

[Nikita91]

Thanks for the info!

[waclawek.jan]

 > Unfortunately, I couldn't find this useful tidbit in the 412KB reference manual.

This is the very purpose of having shadow datetime registers at all.

However, FYI, this mechanism is flawed in most STM32, see RTC calendar registers are not locked properly erratum in many STM32 errata. It's hard to tell whether this applies to the 'L412 too - it's latest (and only) errata are dated 2018 while the above erratum is dated late 2016; but ST refuses to publish detailed list of IPs versions used in individual families/models.

JW

PS. It's also documented in Cube in the doxygenoid "header" to HAL_RTC_GetTime(), in the current (April 2020) version https://github.com/STMicroelectronics/STM32CubeL4/blob/master/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_rtc.c#L859

[Legacy member]

Ugh... That feeling when asking a question, and then getting the exact file, line, and charater in the comment for the actual function presented to me after having claimed to have read the docs. I could have sworn I RTFM.

Thanks for researching the citations.

[waclawek.jan]

Its okay. We all do feel like this from time to time... :) Those beast of manuals have thousands of pages for reason.

JW