zephyr software timer cannot trigger periodically.

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;
Parents
  • 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

  • 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);
    }

Reply
  • 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);
    }

Children
No Data
Related