Restore RTC Clock after power off

[dds90]

How would it be possible to keep the time even after the power supply was restored? Now, when power is restored, the microcontroller restarts from the setup() routine (where there is rtc.setTime), it takes the new time and loses the current time. Is it possible to implement the programmable voltage detector (PVD) to send the microcontroller in low power mode, and wake up when power is restored without going through setup()?

Thank you in advance

[Stateford]

Shouldn't setRTC be a subroutine that can be called on it's on? AFAIK RTC's have an internal battery that keep time.

Maybe this would help?

http://ww1.microchip.com/downloads/en/AppNotes/Atmel-2575-C-Functions-for-Reading-and-Writing-to-Flash-Memory_ApplicationNote_AVR106.pdf

[fpistm]

You talk about after a call of low power shutdown()?

[dds90]

At the moment I have only implemented the RTC and when I remove the power supply and then poweron the discovery board again, the clock starts from the time that I initially set. I suppose this happens because it's like pressing the RESET button, and then I'm going to reinitialize the RTC.

To keep the time even after restoring the power, how should I do?

[fpistm]

Which board? I assume you have a battery connected to VBAT.

[dds90]

I'm trying with a STM32VLDISCOVERY, so STM32F100RBT6. I've connected the battery.

[fpistm]

It required to save the date/time in backup registers using HAL_RTCEx_BKUPWrite/HAL_RTCEx_BKUPRead. This is the first releases of STM32RTC and STM32LowPower, goal was to enable low power which required some RTC services and so this could be extend in further version. Anyway this use case is mandatory: restore Date/time after standby mode. Ido not talk about PVD.

[dds90]

It required to save the date/time in backup registers using HAL_RTCEx_BKUPWrite/HAL_RTCEx_BKUPRead.

I read this too. Would it be appropriate to change the title and remove the PVD? I've read also that there is some issue with the date backup.

Anyway this use case is mandatory: restore Date/time after standby mode.

Do you think that you could process it in a further version?

Moreover, if you will get this board, like you wrote previously, after connected the battery, is necessary to remove the SB1.

[fpistm]

Yes it will be an enhancement. And yes by default VBAT is connected to VDD on ST boards

[dds90]

Indicatively, what times for processing and release do you suppose?

[fpistm]

I don't know exactly. Several stuff in //. I will do my best.

[dds90]

Thank you very very much!

[ppescher]

Hi @fpistm

I think the issue is in the core RTC driver implementation. The RTC_Init() function unconditionally initializes the RTC calendar with an arbitrary date/time. I have a project where we use a separate VBAT and I had to remove the calendar initialization in order to keep the correct date/time.

I'm referring to line https://github.com/stm32duino/Arduino_Core_STM32/blob/e872a357aed81a2eb93e2f134a94e073160b5f52/cores/arduino/stm32/rtc.c#L321 and below:

/*Sunday 1st January 2017*/
RTC_SetDate(17, 1, 1, 7);

/*at 0:0:0*/
RTC_SetTime(0,0,0,0,AM);

In my project I made a simple library to handle backup registers and I set a flag to remember if the calendar has been initialized already. If not, my code uses the STM32RTC library to set the initial date/time (or it could get them from other sources, e.g. NTP or GPS) .

I think calendar initialization should be left to the application and not done in the core. This eliminates the problem of date/time being overwritten when you exit backup (VBAT) mode.

At least that's what I've done in my fork of the core, I just removed those 2 initial calls to RTC_SetDate/RTC_SetTime from "rtc.c".

If you are interested, initial code for a library to handle backup registers can be found at: https://github.com/RoboTech-srl/STM32BackupRegs

[fpistm]

This is not an issue ;) At this time this is just a non implemented feature. https://github.com/stm32duino/STM32RTC/issues/11

[ppescher]

Ah ah... well, it was an issue for me, because I wanted to use backup mode. :-)

The logic behind bool resetTime cannot work as it is now, because the _configured member is always initialized as "false" no matter what, so the RTC peripheral initialization always takes place, and so does setting the inital date/time inside the core driver.

I'm not sure how you planned to handle this, but I was thinking that removing those two calls from the core could do no harm anyway. Are those calls to RTC_SetDate/Time actually required, given that any application will eventually need to set the calendar anyway by its own means in order to use the RTC?

[fpistm]

Currently, I don't know exactly. Initially, the RTC has been added to be used by Low Power mode library. Before merge it I've made a lot of rework compared to the initial PR from wi6labs (library feature which was very limited refer to #235) I must admit that I forgot this feature :'(

[dds90]

Hi @fpistm, When you'll implement the correct RTC restore after power off, do you think to realize a library for use all backup registers, or you'll implement only the date/time backup registers?

[fpistm]

At least date and time but this is opened. This can be take in account to be more generic. Any help/tips are welcome

[dds90]

Hi @fpistm, I've just update the core and the RTC library to the master version. Now the time backup seems to work properly. But the Date haven't a backup yet. Is it correct?

[fpistm]

In fact Date is not saved on F1. https://community.st.com/s/question/0D50X00009XkekSSAR/stm32f103-rtc-vbat-date-resets-after-power-off So you have to use backup register to save it or use the epoch time to convert as a date.