Merged in juniskane/nuttx_stm32l4/stm32l4_rtc_fixes_pr (pull request #509)
STM32L4 small fixes to RTC * STM32L4 RTC: init mode was never exited because nested locking in rtc_synchwait() disabled backup domain access * STM32L4 RTC: use backup register magic value instead of INITS bit The INITS (bit 4) of RTC_ISR register cannot be used to reliably detect backup domain reset. This is because we can operate our device without ever initializing the year field in the RTC calendar if our application does not care about correct date being set. Hardware also clears the bit when RTC date is set back to year 2000: nsh> date -s "Jan 01 00:00:00 2001" rtc_dumptime: Setting time: rtc_dumptime: tm: 2001-01-01 00:00:00 rtc_dumpregs: New time setting: rtc_dumpregs: TR: 00000000 rtc_dumpregs: DR: 00012101 rtc_dumpregs: CR: 00000000 rtc_dumpregs: ISR: 00000037 ... nsh> date -s "Jan 01 00:00:00 2000" rtc_dumptime: Setting time: rtc_dumptime: tm: 2000-01-01 00:00:00 rtc_dumpregs: New time setting: rtc_dumpregs: TR: 00000000 rtc_dumpregs: DR: 0000c101 rtc_dumpregs: CR: 00000000 rtc_dumpregs: ISR: 00000027 <--- Bit 4 went missing! ... This patch allows us to do: stm32l4_pmstop(true); /* Stop mode disables HSE/HSI/PLL and wake happens with default system * clock. So reconfigure clocks early on Stop mode return. */ stm32l4_clockconfig(); without stm32l4_clockconfig() doing spurious and harmful backup domain reset in rcc_resetbkp(). * STM32L4 RTC: put back the SSR race condition workaround ST has confirmed that the issue has not been fixed, and that it applies to STM32L4 too (was not in errata sheets due to documentation bug) See discussion: https://community.st.com/thread/43710-issue-with-rtc-maximum-time-resolution * STM32F4, STM32L4, STM32F7 RTC: add more CONFIG_RTC_NALARMS > 1 to reduce code size * STM32L4: rename stm32l4_rtcc.c to stm32l4_rtc.c to better match STM32F7 Cosmetic changes to comments * STM32, STM32L4, STM32F7 RTC: stray comment and typos in chip/stm32_rtcc.h * STM32L4 RTC: change maximum alarm time from 24h to one month Approved-by: Gregory Nutt <gnutt@nuttx.org>
Loading
Please register or sign in to comment