RTC peripheral and system clock

Hi,

Is there any relationship between RTC peripheral and the system clock (which from DTC it looks like attached to rtc0)?

I'm trying to use PPI to generate a radio task based on system clock compare (i.e. send packet at day:mont:year:hour:minute:second:msec:usec type of event)

The RTC in the peripheral section is too short to contain long enough time span between overflow and I can't find in the documentation a way to invoke PPI from system clock.

Is that possible at all?

Thanks,

Guy.

Parents
  • Maybe not exactly what you are looking for, but the RTC can be extended by using (say) RTC TASKS_TICK->COUNTER/TIMER TASKS_COUNT->COUNTER/TIMER EVENTS_COMPARE[] provided the COUNTER/TIMER is in counter mode.

  • Not quite. I've seen this blog before.

    My goal is to synchronize the wall clock between the 2 devices. My app needs a device with no cloud access to send time stamped messages to the host that has the cloud access on a low latency accuracy. So the host system can correlate the device's message with local events on the host

  • Hi,

    To answer your original questions:

    Is there any relationship between RTC peripheral and the system clock (which from DTC it looks like attached to rtc0)?

    Yes, the kernel timer is based on the RTC peripheral.

    I'm trying to use PPI to generate a radio task based on system clock compare (i.e. send packet at day:mont:year:hour:minute:second:msec:usec type of event)

    The RTC in the peripheral section is too short to contain long enough time span between overflow and I can't find in the documentation a way to invoke PPI from system clock.

    PPI can only be used to connect HW events, the kernel timer is not a HW peripheral but a library/module that use the RTC peripheral. 

    What local tasks/events are you using the kernel timer for, and that you need to be synchronized?

    regards

    Jared

  • I'm not using the kernel timer. 

    I'm using the kernel date service (i.e. write/read wall clock timestamp in some epoch format) 

    I need the 2 devices to be synchronized on their epoch time so using the blog post you mentioned above, my thought is to use the kernel epoch time of the device that is connected to the cloud (which is updated via some kind of time service) and set the other device epoch time with it.

    My idea is to use a timer peripheral to send along with the epoch timestamp and then send periodic timer timestamps to correct any drift on the epoch clock

    Thanks,

    Guy.

  • Hi.

    I haven't really used it before but it seems like the Zephyr system have a module that can be used to synchronize the kernel timer to an external source. 

    Kernel will use RTC0,

    regards

    Jared 

  • That was my initial question: How does this module maintain time? 

    RTC0 is part of peripherals: https://docs.nordicsemi.com/bundle/ps_nrf52833/page/rtc.html

    It only 24 bit long and without setting the prescaler it will overflow after about 500 seconds.

    So if the system clock (wall clock time) is fed from this clock source, something has to compensate for the short duration since EPOCH counts since 1970.

    If there is a prescaler set up by Zephyr, it means that a user has to be careful not to touch RTC0 configuration or it will affect system time base.

    Hence my question: is it using RTC0 as a clock source and care must be taken not to change its settings, or is there a different internal tick that is used to count the time?

    Thanks,

    Guy

  • I do something similar, but had a requirement is to avoid abrupt timejumps which can be achieved by accelerating or decelerating the timestamp; works really well. Resolution vs period on the RTC is the usual tradeoff as you note, but the periodic interrupt takes care of that if EVENT_RTC->TASKS_COUNT->EVENTS_COMPARE is not wanted. 32-bit time value can be converted to date/time as needed

        else if (NRF_RTC1->EVENTS_TICK == 1)
        {
            NRF_RTC1->EVENTS_TICK = 0;
    #if defined(V_AND_V_TEST_CODE)
            nrf_gpio_pin_toggle(TICK_EVENT_OUTPUT);
    #endif
            // 8Hz tick gives us 17 years operation using 32-bit unsigned timers
            // Coin cells are unlikely to last that long, maybe a year or more
            if (mAdjustTickCount < 0)
            {
               // Slow down, don't increment the 125mSec tick
               mAdjustTickCount++;
            }
            else if (mAdjustTickCount == 0)
            {
               // Spot on, usual situation
               mRTC_PacketSampleTimer++;
            }
            else
            {
               // Speed up
               mRTC_PacketSampleTimer+=2;
               mAdjustTickCount--;
            }
         }

Reply
  • I do something similar, but had a requirement is to avoid abrupt timejumps which can be achieved by accelerating or decelerating the timestamp; works really well. Resolution vs period on the RTC is the usual tradeoff as you note, but the periodic interrupt takes care of that if EVENT_RTC->TASKS_COUNT->EVENTS_COMPARE is not wanted. 32-bit time value can be converted to date/time as needed

        else if (NRF_RTC1->EVENTS_TICK == 1)
        {
            NRF_RTC1->EVENTS_TICK = 0;
    #if defined(V_AND_V_TEST_CODE)
            nrf_gpio_pin_toggle(TICK_EVENT_OUTPUT);
    #endif
            // 8Hz tick gives us 17 years operation using 32-bit unsigned timers
            // Coin cells are unlikely to last that long, maybe a year or more
            if (mAdjustTickCount < 0)
            {
               // Slow down, don't increment the 125mSec tick
               mAdjustTickCount++;
            }
            else if (mAdjustTickCount == 0)
            {
               // Spot on, usual situation
               mRTC_PacketSampleTimer++;
            }
            else
            {
               // Speed up
               mRTC_PacketSampleTimer+=2;
               mAdjustTickCount--;
            }
         }

Children
No Data
Related