Hello,
@Louie88 wrote:
Unfortunately, STM does not provide a battery backup socket for us on most of the development boards including STM32H747I-DISCO board...
I do agree with that but not eval boards. Only Disco board are impacted and I was pushing to have at least the access to the VBAT to the users.
@Louie88 wrote:
Now my question is:
If I have battery backup RAM installed and I turn the discovery board on, the CubeMX generated RTC initialization function will modify (overwrite) the RTC date and time registers to its default value. This is what I must avoid because the RTC already contains the exact date and time measured while the board was switched off. How can I do this?
You can have a look at the RTC calendar example on F4:
It's managed by setting a magic number in the backup SRAM. If the RTC was set, the application don't have to initialize it later after reset or a power cycle:
/*##-2- Check if Data stored in BackUp register0: No Need to reconfigure RTC#*/
/* Read the Back Up Register 0 Data */
if(HAL_RTCEx_BKUPRead(&RtcHandle, RTC_BKP_DR0) != 0x32F2)
{
/* Configure RTC Calendar */
RTC_CalendarConfig();
}
else
{
/* Check if the Power On Reset flag is set */
if(__HAL_RCC_GET_FLAG(RCC_FLAG_PORRST) != RESET)
{
/* Turn on LED2: Power on reset occurred */
BSP_LED_On(LED2);
}
/* Check if Pin Reset flag is set */
if(__HAL_RCC_GET_FLAG(RCC_FLAG_PINRST) != RESET)
{
/* Turn on LED4: External reset occurred */
BSP_LED_On(LED4);
}
/* Clear source Reset Flag */
__HAL_RCC_CLEAR_RESET_FLAGS();
}
In this case the magic number used was 0x32F2. You can use any other magic number.
PS: I think 0x32F2 value was chosen as the first RTC calendar peripheral version has been adopted on STM32F2 product. And the example above was developed at first time on this product.
Hope that answers your question.
