Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Add date retention functionality for STM32F1xx based boards #41

Closed
wants to merge 12 commits into from

Conversation

josh-gaby
Copy link

Adds date retention through power cycles on stm32f1xx based boards

On these chips, the date details are only stored in SRAM while running, because of this, dates are not being retained after a power off even with VBAT connected.

This is fixed by using backup registers DR2 and DR3 to store the date data each time it is updated. Doing this means that the date can then be extracted and set correctly when the RTC is next initialized.

Add date retention functionality for STM32F1xx based boards
@josh-gaby josh-gaby reopened this Sep 23, 2020
Remove spaces to pass AStyle check
@fpistm
Copy link
Member

fpistm commented Sep 23, 2020

Hi @josh-gaby
Thanks for moving this PR here.

Only run RTC_StoreDate from the SetDate function if running on stm32f1xx
Josh added 2 commits September 25, 2020 11:19
Store the date after a rollover on power up or it will revert if power is lost again before manually changeing or another rollover occurs.
@fpistm fpistm requested a review from FRASTM January 5, 2021 10:09
src/rtc.c Outdated Show resolved Hide resolved
src/rtc.c Show resolved Hide resolved
Josh added 6 commits February 24, 2021 12:00
Add a backup register definition
Fix code styling
Correct backup register
Retain weekday through power cycle
Add check for valid weekday when restoring date
Fix typo
src/rtc.c Show resolved Hide resolved
Include missing header file
@fpistm
Copy link
Member

fpistm commented Apr 20, 2021

Hi @josh-gaby
Seems this PR does not cover all possible case (mainly when date change during a sleep mode):
bxparks/AceTime#50 (comment)

I don't think I'm a fan of this PR, because if I understand it correctly, the date is not updated while the microcontroller is powered-down. The date is only preserved, so it is good for short power-loss. If the controller is powered down for more than 24 hours (or maybe even across the 23:59 -> 24:00 transition), the date is incorrect.

I think using epoch time to restore the date is a better solution and will cover all the case.

@fpistm fpistm modified the milestones: 2.0.0, 2.x.x Apr 22, 2021
@fpistm fpistm modified the milestones: 1.1.1, 1.2.0 Oct 1, 2021
@fpistm fpistm linked an issue Nov 17, 2021 that may be closed by this pull request
src/rtc.c Show resolved Hide resolved
src/rtc.c Show resolved Hide resolved
@FRASTM
Copy link
Contributor

FRASTM commented Nov 23, 2021

Thanks to a "magic nb" in another backUp register, there is a simple way to detect if the Vbat was powered during Vdd OFF.
Then the date read is considered as valid or not.

@FRASTM
Copy link
Contributor

FRASTM commented Dec 1, 2021

This proposal looks like a custom appli as long as only the date is kept (stored) on each call to rtc.setDate.
Keeping the date and/or time in the backUp reg will guarantee that, on the next Reset, the RTC will start counting from this value and not from 0.
It should be extended to date and time (checking the 'reset' flag of the RTC_init). This is quite simple when Read/Writing the RTC CNT counter registers exporting cube HAL functions (just like the MBED did for the stm32F1)

On the stm32F1 there is one-second interrupt (see #57) that could help storing the new Date and/or Time in BackUp Registers.
In any case the RTC and backup Registers can be powered by the Vbat and kept supplied when the main Vdd is off.
If not the content is lost.

@josh-gaby
Copy link
Author

Its been awhile since I've had a chance to work on this, I will try and get back on it this weekend.

@drbachler
Copy link

I just ran into this, would be awesome to get this fix across the line and merged.

@fpistm
Copy link
Member

fpistm commented Dec 16, 2021

I close this PR as it is superseded by #58.

@fpistm fpistm closed this Dec 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants