RTC peripheral and system clock

[GuyYaniv]

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.

[hmolesworth]

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.

[GuyYaniv]

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

[Jared]

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

[GuyYaniv]

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.

[Jared]

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 

[GuyYaniv]

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

[hmolesworth]

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

[Hung Bui]

Hi Guy,

I'm taking over the ticket from Jared. 

Please give us some more information about the time sync requirement you have. What's the accuracy level you want to achieve ? 

Can you tell a little bit more about the device connected to the cloud. Is it a nRF device ? or it's a phone ? 
As far as I know the kernel use RTC1 for keeping time. 

config NRF_RTC_TIMER
	bool "nRF Real Time Counter (NRF_RTC1) Timer"
	depends on CLOCK_CONTROL
	depends on SOC_COMPATIBLE_NRF
	select TICKLESS_CAPABLE
	select NRF_HW_RTC1_RESERVED
	help
	  This module implements a kernel device driver for the nRF Real Time
	  Counter NRF_RTC1 and provides the standard "system clock driver"
	  interfaces.

RTC0 is also reserved if you use BLE (MPSL module). 

What left is available for you to use for time sync (RTC or TIMERs). Jared has sent you the blog on how to do time sync between 2 device. 

From what you described earlier, you want to sync them with wall clock time / epoch time. I would suggest to use the synchronized timer to count time instead of using the uptime from Zephyr (depends on the accuracy you are looking at). You can use the CC event as the tick to count time. This way you don't have to deal with the drift on the uptime/RTC1. 

[GuyYaniv]

Hi Hung,

My requirement is to send timestamped messages from the non-cloud connected device to the cloud connected device. These messages convey sensor data that is affected by the system connected to the cloud connected device. So for the cloud connected device to be able to associate the configurations applied to the system and the sensor readings, the time needs to be synced.

I've neglected the idea of using the wall clock. A free running timer should be good enough for this purpose.

The accuracy should be sub 1 ms (shooting for 500us).

My question was basically what you described: RTC1 and RTC0 and being used by the kernel.

So, if I call NRF_RTC1->TASKS_STOP it will affect the kernel uptime.

Is that a correct statement?

Thanks,

Guy.

[Hung Bui]

Hi Guy,

GuyYaniv said:

So, if I call NRF_RTC1->TASKS_STOP it will affect the kernel uptime.

Yes, you are correct.