Skip to main content
Visitor II
March 28, 2024
Solved

STM32 RTC3 Mixed Mode: Writing TR resets SSR?

  • March 28, 2024
  • 1 reply
  • 1451 views

RTC3 of some newer STM32s introduce a RTC mixed mode, where both binary part (32-bit down-counting sub-seconds register SSR) and classic BCD calender (TR/DT) mode are operational.

In my case I am using this for classic style BCD alarms together with binary mode timers used by the CubeMX generated LoRaWAN stack.
This works perfectly fine until I try to set the BCD calender time part with HAL_RTC_SetTime.

It turned out, that as soon as RTC->TR is written, RTC->SSR is reset to 0xFFFFFFFF. As all timers backed by the binary mode rely on some SSR timestamp, they fail.

I tried backing up SSR and writing back after RTC->TR write, but it seems to be read-only.

Am I missing something? If a mixed mode has been introduced, I doubt normal behaviour is that the BCD part cannot be set anymore without affecting the binary mode part.

    This topic has been closed for replies.
    Best answer by waclawek.jan

    This matches the description in RM:

    waclawekjan_0-1711704158784.png

    The reason for this is to ensure that the first calendar (seconds) increment happens exactly one second after the initialization is finished (i.e. that the calendar can be run sub-second perfect).

    > As all timers backed by the binary mode rely on some SSR timestamp, they fail.

    I don't know what that exactly means, but the possible workaround would probably be related to shifting those "timers" (which I presume are some software constructs) appropriately.

    JW

     

    1 reply

    Super User
    March 29, 2024

    This matches the description in RM:

    waclawekjan_0-1711704158784.png

    The reason for this is to ensure that the first calendar (seconds) increment happens exactly one second after the initialization is finished (i.e. that the calendar can be run sub-second perfect).

    > As all timers backed by the binary mode rely on some SSR timestamp, they fail.

    I don't know what that exactly means, but the possible workaround would probably be related to shifting those "timers" (which I presume are some software constructs) appropriately.

    JW

     

    Visitor II
    March 29, 2024

    Ok, I see, thanks a lot!
    Yes, this workaround would probably work, thanks for the suggestion. I took the other route now and decided to go with binary mode all along and calculate hh:mm style alarms myself.

     

    Robert