zephyr software timer cannot trigger periodically.

[hjq]

I am using the NRF54L05.When I was using the timer function of the Zephyr software, I created a timer with a 10ms cycle. After my system had been running for a long time (for example, 12 hours), after executing sys_reboot(SYS_REBOOT_COLD);, there was a probability of encountering a timer anomaly. It did not trigger as I expected; it only triggered once, and the next trigger time was much later;

相关代码使用：   

FRAME_INTVAL_UINT 10  // 毫秒

  k_timer_init （& delay_timer ，delay_timer_handler ，NULL ）；

  k_timer_start （& delay_timer ，K_MSEC （（uint32_t ）FRAME_INTVAL_UINT ），

                K_MSEC （（uint32_t ）FRAME_INTVAL_UINT ））；

I obtained the trigger count and the next time from the delay_timer through k_timer_status_get(&delay_timer) and k_timer_remaining_get(&delay_timer) respectively.The results I got were 1 and 11814496;

I can confirm that my clocks are all functioning properly, and my delay_work and threads are also running normally. I have no idea how to proceed to identify the problem;

Thank you very much for your help;

[Benjamin]

Hi,

I have some follow up questions before we proceed:

there was a probability

What would you estimate this probability to be? How many times have you encountered this issue?

Does this happen only when your system has run for 12h + and then right after sys_reboot(SYS_REBOOT_COLD) ?

Have you encountered the issue using the timer with a different period?

What is going on in your expiration function?

Best regards,
Benjamin

[hjq]

Hi,

This problem was discovered during the aging test of the produced equipment. After being left overnight, it was found that 90% of the equipment was unable to operate normally the next day.

This problem will 90% likely occur if left overnight.

The equipment was still functioning normally before the sys_reboot (SYS_REBOOT_COLD) operation. During the product development stage, we accidentally discovered that the timer seemed to have a problem of not starting. Later, we no longer used it. In the subsequent development process, we had to send task events precisely at the exact time, and then we could use it again. As expected, this problem occurred again.

Finally, I would like to add that the SDK version I used was 2.9.2. I also employed ANT and BLE.

Here is my expiration function:

void delay_timer_handler(struct k_timer *timer) {
  static uint8_t cnt = 0;
  // printk("1\n");
  cnt++;
  if (cnt >= 100) {
    cnt = 0;
    k_event_post(&light_event, LIGHT_TIME_1S_EVENT | LIGHT_TIME_EVENT);
  } else
    k_event_post(&light_event, LIGHT_TIME_EVENT);
}

[hjq]

HI,

Yesterday, I conducted a control experiment. Each group consisted of 5 devices. The periodic timer was initialized and started at the beginning of the main function. Then, a comparison was made with the previous usage method. After one day, all the devices in the control group failed, while all the devices in the experimental group were normal. Could this be related to the channel allocation of GRTC?

[Benjamin]

Hi,
Sorry for the delay. That’s interesting, but I’m not sure I fully understand the differences. So in one group, the timer worked as expected? Could you share a clear list of what you did differently between the devices that failed and those that didn’t?

Regards,
Benjamin

[hjq]

Hi,

I apologize for providing incorrect information. After further experiments, it was found that the equipment in the experimental group still had the same problem.

[Benjamin]

Hi,
Do you have any application logs that demonstrate this issue?

Regards,
Benjamin