RTC Alarm interrupt after 48 days in ST LoRa middlewares. What it happens?

[MBare.1]

Hi,

I have a question related to the working principle of RTC in the LoRa middleware I-CUBE-LRWAN and STM32CubeWL.

I'm working on the firmware for custom boards based on development boards both B-L072Z-LRWAN1 and the more recent NUCLEO-WL55JC1.

My projects should work for years on LoRaWAN public network and I noticed a comment in the user manuals about the duration (48 days) of RTC both LoRa middleware. 

Here in I-CUBE-LRWAN (UM2073)

and here in STM32CubeWL documentation (AN5406)

What I observed looking at the firmware (example End_Node, TX_ON_TIMER) is that RTC is configured in free-running mode using binary mode. 

Default configuration has LSE activated and it is clocked at 32.768 kHz. This means that each second we have an increment of 32768 units in the 32-bit RTC free-running counter register that is used to timing the LoRa stack and alarms (and wake-up the machine from low-power modes). Moreover, after around 48 days we have the overflow of this 32-bit RTC free-running counter register.

At first sight, I think that when we are close to the overflow of the counter, all future set-up alarms, that overcomes the width of the 32-bit counter, will overflow themselves, moreover, they will be corrected set up and they will wake up the machine after 48 days.

Is it right this last statement and it will work properly after 48 days?

Or LoRa middleware will not work properly after 48 days? In this last case, which is the appropriate solution to handle a project that it should work for months/years? Save all LoRa variables in non-volatile memories, reset the micro and re-upload these variables to avoid re-join to the LoRaWAN public network?

Best regards,

MBare

[Tesla DeLorean]

Closer to 49.71 days, but..

It's more of a "think about it" problem, where you're aware to it occurring rather than being surprised, that you test things over a longer time span.

That you take this into account with all that you do, that you wake up at least once every 7 weeks, and that you track long-term-time in some other units than 32-bit milliseconds. That perhaps you use hours , days or weeks, as a long count, so code wouldn't need to fixed within a century.

That you have and report up-time metrics, and that team members understand they'll be judged on reliability.

That you use 32-bit unsigned numbers to do the math on the millisecond ticks, and use relative measurements and comparisons rather than when ticks >= x, or similar naive constructs. And don't have timeouts exceeding the constraints of the count. That you be vigilant with scaling up/down of numbers within that space, and that 32-bit binary counts don't fit conveniently into HH:MM:SS.sss / YYYY-MM-DD human/earth centric.

Test all time and calendar code.

You shouldn't need to reset things if you design them to run continuously for years.

https://www.theregister.com/2020/04/02/boeing_787_power_cycle_51_days_stale_data/