In my project I have configuration parameter, defining period of unsolicited reports for sensor values. It's value by default equals 43200 seconds, or 12 hours.
To setup this value for EM4 application timer I am using function `AppTimerEm4PersistentStart`, which in turn calls `TimerStart`. The value of delay must be specified in *ms*, so I should pass time delay value equal 43200 * 1000 ms. BUT, timer callback is being fired in approximately 4 mins instead of 12 hours!
And here is the thing. Structure `SSwTimer` storing timer's state, also stores timeout delay in *ms* which is set after `TimerStart` call. For "small" values of delay value of this field in `SSwTimer` isn't being changed after `TimerStart` call. But for large values, e.g. 12 hours, or 43200 * 1000 ms, value is being changed very odd.
After some iteration calculations I found out, that maximum value which isn't being distorted by `TimerStart` equals 4 294 967 ms or approximately *1h 10min*. If we are passing value 1ms larger, then value is being looped and instead of (4 294 967 + 1)ms I have 0ms delay.
So, if we want to create 12 hours delay then it MUST be done some workaround - store *counter* of hours in NVM for each EM4 timer with "big" time period. This counter are being decremented each 1 hour using `AppTimerEm4PersistentStart` (the value of 1h is a bit lower then acceptable delay 1h 10min), and when value of this counter becomes equal 0, then it should be passed remainder of time (less then 1hour) to `AppTimerEm4PersistentStart`.
I can suppose what's the problem in `TimerStart`. Max value which can be passed to this function by specified data type (32 bits for `TickType_t`/ `uint32_t`) is 0xFFFFFFFF (also as for `portMAX_DELAY`) or 4 294 967 295 ms, but indeed really correct value is less or equal 4 294 967ms.
This correct value is exactly 1000 times smaller then max acceptable by `TimerStart`. So may be in function implementation there are some calculations, in which value of delay in *ms* is being multiplied by 1000 and then divided by the same value, overflowing data type's storage capacity (32 bits), and the value is being cycled.
I checked this also for *SensorPIR* from last SDK v.7.11.1 and problem is still taking place.