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

drivers: counter: stm32: fix alarm time calculation #32262

Merged

Conversation

Antonis510
Copy link
Contributor

@Antonis510 Antonis510 commented Feb 12, 2021

The calculated alarm time starts from 2000 but the gmtime_r needs as
input the time from epoch (1970). This causes the alarm time to be
miscalculated due to leap years, as 2000 is a leap year and 1970 is not.
To fix the issue, the 2000 timestamp can be added to the input time of
gmtime_r.

Fixes #32260

Signed-off-by: Antonis Sioutas antonis.si510@gmail.com

@Antonis510 Antonis510 force-pushed the fix_stm32_driver_counter branch 2 times, most recently from fbe745d to 9f1328d Compare February 12, 2021 11:51
The calculated alarm time starts from 2000 but the gmtime_r needs as
input the time from epoch (1970). This causes the alarm time to be
miscalculated due to leap years, as 2000 is a leap year and 1970 is not.
To fix the issue, the 2000 timestamp can be added to the input time of
gmtime_r.

Fixes zephyrproject-rtos#32260

Signed-off-by: Antonis Sioutas <antonis.si510@gmail.com>
@erwango erwango requested review from ABOSTM and FRASTM February 12, 2021 13:25
@erwango erwango added the bug The issue is a bug, or the PR is fixing a bug label Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Counter bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32
Projects
None yet
Development

Successfully merging this pull request may close these issues.

STM32 counter driver error in estimating alarm time
4 participants