high precision timer in nrf5340

Hi.

     I am currently working on a project utilizing the nRF5340 platform and have encountered an issue with the timing precision when using the k_timer_start() function. I have noticed a deviation of approximately 3%, and I am reaching out to seek assistance in resolving this matter.

In my application, I am utilizing k_timer_start() to trigger events at intervals of 20 milliseconds. However, during my analysis, I observed that the timing is not consistently accurate, leading to the aforementioned deviation.

Considering the precision requirements of my application, I am interested in exploring alternative high-precision timers available on the nRF5340 platform. Could you kindly provide guidance or recommend any specific timers that offer higher accuracy and stability compared to the standard k_timer_start() function?

 

Parents
  • Hi c3_nithin,

    From the Timers service documentation, you can see an explanation for part of the deviation observed:

    Note that the timer’s duration and period parameters specify minimum delays that will elapse. Because of internal system timer precision (and potentially runtime interactions like interrupt delay) it is possible that more time may have passed as measured by reads from the relevant system time APIs. But at least this much time is guaranteed to have elapsed.

    Besides this, you might want to know that the Kernel timing, including the Timers service, are based on the RTC0 Peripheral. The RTC peripherals run off of the Low-frequency Clock (LFCLK), which is less precise than the TIMER peripherals which run off the High-frequency Clock (HFCLK).

    Please also know that both of those clocks also can be sourced from a respective internal RC oscillator (LFRC, HFINT), or from an external crystal circuit (LFXO, HFXO). The external sources' precision depends on the crystal and circuit but is most often more precise than the internal RC oscillator source.

    You can look up the details of those terms and keywords in the Clock Control section of the nRF5340 Product Specification. The precision of each option is available in the Electrical Specification subsection of that page. You can determine the option that matches your precision requirement and implement based on it.

    There are several existing cases on DevZone about such implementations that you can lookup. However, if you still have difficulties, please feel free to reply here.

Reply
  • Hi c3_nithin,

    From the Timers service documentation, you can see an explanation for part of the deviation observed:

    Note that the timer’s duration and period parameters specify minimum delays that will elapse. Because of internal system timer precision (and potentially runtime interactions like interrupt delay) it is possible that more time may have passed as measured by reads from the relevant system time APIs. But at least this much time is guaranteed to have elapsed.

    Besides this, you might want to know that the Kernel timing, including the Timers service, are based on the RTC0 Peripheral. The RTC peripherals run off of the Low-frequency Clock (LFCLK), which is less precise than the TIMER peripherals which run off the High-frequency Clock (HFCLK).

    Please also know that both of those clocks also can be sourced from a respective internal RC oscillator (LFRC, HFINT), or from an external crystal circuit (LFXO, HFXO). The external sources' precision depends on the crystal and circuit but is most often more precise than the internal RC oscillator source.

    You can look up the details of those terms and keywords in the Clock Control section of the nRF5340 Product Specification. The precision of each option is available in the Electrical Specification subsection of that page. You can determine the option that matches your precision requirement and implement based on it.

    There are several existing cases on DevZone about such implementations that you can lookup. However, if you still have difficulties, please feel free to reply here.

Children
No Data
Related