cpu/stm32/periph/rtc overflow error

[aidiaz]

Description

RTC time not overflowing on tests/periph_rtc on BOARD=bluepill-128kib

Steps to reproduce the issue

Run tests/periph_rtc on BOARD=bluepill-128kib

Expected results

Help: Press s to start test, r to print it is ready
s
START
main(): This is RIOT! (Version: 2021.07-devel-245-g9c749b)

RIOT RTC low-level driver test
This test will display 'Alarm!' every 2 seconds for 4 times
 Setting clock to   2020-02-28 23:59:57
Clock value is now   2020-02-28 23:59:57
 Setting alarm to   2020-02-28 23:59:59
  Alarm is set to   2020-02-28 23:59:59
 Alarm cleared at   2020-02-28 23:59:57
      No alarm at   2020-02-28 23:59:59
 Setting alarm to   2020-02-29 00:00:01

Alarm!
Alarm!
Alarm!
Alarm!

Actual results

As shown, the alarm time doesn't overflow, and counts seconds up to 61.

Help: Press s to start test, r to print it is ready
s
START
main(): This is RIOT! (Version: 2021.07-devel-245-g9c749b)

RIOT RTC low-level driver test
This test will display 'Alarm!' every 2 seconds for 4 times
 Setting clock to   2020-02-28 23:59:57
Clock value is now   2020-02-28 23:59:57
 Setting alarm to   2020-02-28 23:59:59
  Alarm is set to   2020-02-28 23:59:59
 Alarm cleared at   2020-02-28 23:59:57
      No alarm at   2020-02-28 23:59:59
 Setting alarm to   2020-02-28 23:59:61

Alarm!
Alarm!
Alarm!
Alarm!

Versions

Operating System Environment
----------------------------
         Operating System: "Ubuntu" "20.04.2 LTS (Focal Fossa)"
                   Kernel: Linux 5.8.0-55-generic x86_64 x86_64
             System shell: /usr/bin/dash (probably dash)
             make's shell: /usr/bin/dash (probably dash)

Installed compiler toolchains
-----------------------------
               native gcc: gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
        arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)
                  avr-gcc: missing
         mips-mti-elf-gcc: missing
           msp430-elf-gcc: missing
       riscv-none-elf-gcc: missing
  riscv64-unknown-elf-gcc: missing
     riscv-none-embed-gcc: missing
     xtensa-esp32-elf-gcc: missing
   xtensa-esp8266-elf-gcc: missing
                    clang: missing

Installed compiler libs
-----------------------
     arm-none-eabi-newlib: "3.3.0"
      mips-mti-elf-newlib: missing
        msp430-elf-newlib: missing
    riscv-none-elf-newlib: missing
riscv64-unknown-elf-newlib: missing
  riscv-none-embed-newlib: missing
  xtensa-esp32-elf-newlib: missing
xtensa-esp8266-elf-newlib: missing
                 avr-libc: missing (missing)

Installed development tools
---------------------------
                   ccache: missing
                    cmake: cmake version 3.16.3
                 cppcheck: missing
                  doxygen: missing
                      git: git version 2.25.1
                     make: GNU Make 4.2.1
                  openocd: Open On-Chip Debugger 0.10.0+dev-01119-g092cfe16f (2021-05-27-18:20)
                   python: missing
                  python2: Python 2.7.18
                  python3: Python 3.8.5
                   flake8: error: /usr/bin/python3: No module named flake8
               coccinelle: missing

[maribu]

This is actually not an issue with the driver: The applications asks for an alarm at 2020-02-28 23:59:61 and the drivers generates an alarm at 2020-02-29 00:00:01.

Other implementations of the RTC do normalize the struct tm holding the target time, so that after the call to rtc_timer_set_alarm() the target value is normalized, if it wasn't so before. The RTC driver of the STM32F1 is more a real time counter rather than a real time clock (it uses something similar to UNIX timestamps rather than struct tm). Hence, it doesn't really care if the time is normalized or not.

Other drivers actually need to write the time broken into year, month, day, hour, minute, and second into different registers. They do need a normalized time and will therefore normalize the target time before applying it.

The API doc didn't state anything about normalizing or not normalizing the target time. This of course is an issue, as inconsistent behavior then is surprising. In #19610 the doc is improved so that the behavior here is clearly defined as one of the two valid approaches to denormalized target times.