STM32WLE5CC Lorawan get reset when HAL_Gettick() overflows

[DBhut.1]

Hello,

Our Devices(50 devices) uses STM32WLE5CC and STM32WL V1.0.1 SDK.

I have generated code with Lorawan. All system works perfectly for around 49 days, after that all devices get reboots.

We found that it happens when HAL_Gettick() overflows(we send HAL_Gettick() value to our server on each uplink).

I didn't use HAL_Gettick() function in any other function expect dding this value in lorawan frame , but uses Timer API to create timer and wake device on time.

Please guide us how can I solve this issue?

Currently can't generate issue again as it needs 49 days to overflow HAL_Gettick(). Is there any method I can set HAL_Gettick() time manually so I can be sure about that.

Thank You

[Tesla DeLorean]

At a millisecond level the wrap is closer to 49 days. Make sure all the comparisons using HAL_GetTick() subtract out the starting basis, and watch for divide by zero cases. And watchdogs.

Should be a uwTick variable in stm32wl??_hal.c or similar, use grep / find-in-files

extern volatile uint32_t uwTick;

[DBhut.1]

Sorry Wrap is 49 days(updated in post), and In STM32WL uses RTC_SSR register for HAL_Gettick().

there is no divide by 0 case. and if watchdog case, then why on overflow only.

is there any bug in RTC lib in STM32WL?

[DBhut.1 · Accepted solution]

I have not enabled

RTC Tamper, RTC TimeStamp, LSECSS and RTC SSRU Interrupts

Is this can be issue of MCU Reset?

[DBhut.1]

 

As Shown in images in 1st one SSRU underflow interrupt is enabled, but

"RTC Tamper, RTC TimeStamp, LSECSS and RTC SSRU Interrupts" is not enabled?

Is this case cause to reset of MCU?

[Tesla DeLorean]

I don't know, you'll have to walk the code and documentation to understand the mechanics of the failure.​