• State Not Answered
  • Replies 4 replies
  • Subscribers 86 subscribers
  • Views 261 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 358643
Options

k_cycle_get_64() not implemented for NRF RTC timer driver

jithurm


Hi,

I noticed that when using nrf5340 and it's kernel timer driver, that the k_cycle_get_64() API is not available, and that TIMER_HAS_64BIT_CYCLE_COUNTER is not being set when compiling for nrf5340 SoC. This gets selected when using GRTC for nrf54 devices.

I don't understand why, because checking the driver implementation, I can see that the 32 bit variant in sys_clock_cycle_get_32() is using the 64 bit result of z_nrf_rtc_timer_read() and casting it to uin32t_t. If I understood right the RTC peripheral is using 24 bit counter and already handles the count + overflow logic in a 64 bit counter, so is there any reason why sys_clock_cycle_get_64 could not be implemented by just returning z_nrf_rtc_timer_read() return value, and TIMER_HAS_64BIT_CYCLE_COUNTER selected automatically by the driver ?

We would love to use k_cycle_get_64() in our platform that is using both nrf53 and nrf54 SoC family products for accurate data timestamps, so it would be much appreciated if this would work for nrf5340. 

Thank you in advance for your answer,

Best regards,

Jimmy

  • 0

    I've implemented as a patch that TIMER_HAS_64BIT_CYCLE_COUNTER gets selected by NRF RTC timer driver and added sys_clock_cycle_get_64() implementation to return z_nrf_rtc_timer_read(), and I noticed no issues with overflowing on 32 bits from observing timestamps increasing correctly over several days (it would have overflown after 36 hours) but I can see it seems to be a real 64 bit counter. 

    I'm wondering if this fix could be make in Zephyr upstream. I would like to have validation from experts on this matter beforehand.

  • 0 in reply to jithurm

    Hi,

     

    My apologies for the late reply. 

    jithurm said:
    I've implemented as a patch that TIMER_HAS_64BIT_CYCLE_COUNTER gets selected by NRF RTC timer driver and added sys_clock_cycle_get_64() implementation to return z_nrf_rtc_timer_read(), and I noticed no issues with overflowing on 32 bits from observing timestamps increasing correctly over several days (it would have overflown after 36 hours) but I can see it seems to be a real 64 bit counter. 

    I'm wondering if this fix could be make in Zephyr upstream. I would like to have validation from experts on this matter beforehand.

    I cannot see a direct issue why such a patch should not be accepted, other than possibly that the nRF51/nRF52/nRF53-series devices run this same kernel timer library (ie. high risk to change).

    I am checking internally if there is any direct reason why this was not implemented, but I have not yet heard anything from key-personnel on this matter. I will update you as soon as I hear anything.

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Håkon,
    Thank you for the update. For now we have no plans to use nrf52/51 devices and as it seem to work fine with nrf5340 we'll keep this patch until further notice. It would be better of course to not have to apply patches Zephyr / NCS, but we can manage this way for now.

  • 0 in reply to jithurm

    Hi Jimmy,

     

    jithurm said:
    Thank you for the update. For now we have no plans to use nrf52/51 devices and as it seem to work fine with nrf5340 we'll keep this patch until further notice. It would be better of course to not have to apply patches Zephyr / NCS, but we can manage this way for now.

    Glad to hear that this is working as intended on your end.

    I will add this as a feature request to the team internally.

     

    Kind regards,

    Håkon

Related
Terms of service