Usage of RTC0 as time basis (system time) possible?

RE: Usage of RTC0 as time basis (system time) possible?

puz_md — Mon, 13 Feb 2017 14:58:42 GMT

Hi Anna,

I was using RTC0 only to get some timestamps for short time interval measurements. As RTC0 was already running, I didn't want to waste ressources and energy for using one more timer. Although this strategy worked very well in my prototypes, I would not suggest to use RTC0 in your final (series) product. Just like Stefan mentioned, there is no guarantee thet RTC0 will always be running in an endless loop.

Which timer would be the best choice for your project depends on what you want to do with it. The RTCs are very energy efficient, but they are only 24 bits wide. Maybe the normal timers (which are 32 bits wide and provide more features) would fit your requirements better. Especially if you need higher precision timing = fast input clock, which would need the high frequency crystal to be activated (needs more energy in sleep phases).

Just take a look at the nRF Product Specification (chapters TIMER and RTC), I think they have a very good documentation of their hardware.

If you just used RTC0 like I did, you might want to use RTC1 or RTC2 (doesn't really matter which instance, as long as it is not used by other software modules) to keep the changes in code down to a ninimum. I encapsulated my RTC0 access into a small module / function called getTimestamp(). This way, I can easily replace RTC0 with RTC1 later.

Good luck, Michael

RE: Usage of RTC0 as time basis (system time) possible?

annapalu — Fri, 10 Feb 2017 14:06:42 GMT

Hi puz_md,

i have the some problem. I'm thinking to use a RTC2, even if RTC0 or RTC1.

What do you think about that?

Thanks, Anna

RE: Usage of RTC0 as time basis (system time) possible?

puz_md — Tue, 27 Jan 2015 15:37:55 GMT

Okay, I think your update makes it clear: Even if it seems to work at the moment, it's against the specification and there is no guarantee that it will work in a reliable manner. Thanks!

RE: Usage of RTC0 as time basis (system time) possible?

RK — Sat, 24 Jan 2015 01:10:17 GMT

Even if currently RTC0 ran constantly, never stopped and was never reset and you could read it as you suggest, basing your application on that would be a very bad idea. The softdevice implementation could change at any time, in any way, to run, not run, reset the counter etc. as part of Nordic's softdevice evolution.

You should treat the resources which are documented as used by the softdevice as unavailable for any purpose unless there's an exposed user API point or a documented exception.

RE: Usage of RTC0 as time basis (system time) possible?

puz_md — Fri, 23 Jan 2015 16:10:31 GMT

Hi Stefan,

there might be a misunderstanding in your interpretation of my question. I do NOT intend to do any write operations to RTC0, neither change its configuration that was made by the SoftDevice. All I want to do is use it as a constantly running counter (I am also aware that there will be an overflow every 512 seconds).

Accessing RTC0 is not a problem: I can read NRF_RTC0->COUNTER anytime, from within on_ble_evt() for example. That's all I need to do.

My question is: Is there any situation when this counter is stopped or manually reset/written by the SoftDevice? Or can I use it as a reliable time reference?

RE: Usage of RTC0 as time basis (system time) possible?

Stefan Birnir Sverrisson — Fri, 23 Jan 2015 15:19:15 GMT

When the softdevice is enabled, the RTC0 is blocked, so you would need to disable the softdevice to use the RTC0. Many of the nRF51 SDK BLE example use app_timer library which uses RTC1 in the background, so if you have app_timer enabled, you can not use RTC1 either.

The current consumption is ~0.1uA for the RTC so it is relatively very low current consumption. So there is practically no current cost of using the RTC1, if that is your concern.

Most of the current consumption is during radio events. The largest factors are radio RX ~13mA, radio TX ~10.5mA, CPU ~4.1mA. The softdevice conumes ~3.1uA when idle and enabled. Usually, advertising is more current consuming than being in a connection. More on current connection on this thread.

Putting the chip into System On sleep mode is actually just disabling the CPU. Putting the chip into System Off sleep mode is actually just disabling the CPU and all nRF51 peripherals.

Update 27.1.2015 RTC0 is listed as "blocked" in the SDS. That means that it is in use by the SoftDevice when the SoftDevice is enabled, and the application should not assume anything about the state of this peripheral.