Clarifications on errata "[20] RTC: Register values are invalid"

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Emil Lenngren — Fri, 27 Sep 2024 07:36:13 GMT

Thanks! I'll ignore it then since I haven't seen any issues either. Just wanted to make sure.

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Susheel Nuguru — Fri, 27 Sep 2024 07:33:14 GMT

[quote user="Aryan"]This said, the SDK libraries and drivers does not seem to have applied this workaround and I am not sure why. I need to ask this to the hardware engineers and the SDK team. [/quote]

Yes Emil,

There might have been a misunderstanding on the fix here. If you have some protocol stack that is initialized then it uses some RTC instance and will never let the LF-clock shutoff. So that makes the RTC what ever is used by application not idle. It looks like the core issue with this errata is the lfclock regulator and not just RTC being idle. There are 0 customers out of hundreds of thousand who have complained on wrong RTC values, So I am guessing that it is safe to ignore the workaround if you have any protocol stack initialized.

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Emil Lenngren — Tue, 24 Sep 2024 15:00:20 GMT

[quote userid="6207" url="~/f/nordic-q-a/114001/clarifications-on-errata-20-rtc-register-values-are-invalid/498946"]I need to ask this to the hardware engineers and the SDK team. [/quote]

Hi. Did you receive any reply yet?

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Susheel Nuguru — Tue, 20 Aug 2024 05:08:24 GMT

[quote user="Emil Lenngren"]

From the above, it seems like "idle" means any time after RTC has been used until the next time RTC is used.

Doesn't that contradict your reply for my initial first question?

[/quote]

RTC idle means that the power regulator to it and the LFCLK most likely have been turned off. In the SDK and the protocol stacks, it looks like once the RTC is initialized, it is never allowed to go into idle states where the hardware power management will at any state decide to turn off power and clock to it as the part of automatic power management of a peripheral. This automatic power management to my understanding may happens when you have TASKS_STOP on RTC after it has been started and being used for a while.

This said, the SDK libraries and drivers does not seem to have applied this workaround and I am not sure why. I need to ask this to the hardware engineers and the SDK team.

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Emil Lenngren — Mon, 19 Aug 2024 13:31:29 GMT

Thanks for the quick reply. It makes most things clear now.

However,

[quote userid="6207" url="~/f/nordic-q-a/114001/clarifications-on-errata-20-rtc-register-values-are-invalid/498866"]I think that the condition where RTC is idle is never reached the way rtc drivers and libraries are written. That means that the drivers and libraries make sure that from the time RTC is initialized, there is no instance where it gets to IDLE state.[/quote]

From the above, it seems like "idle" means any time after RTC has been used until the next time RTC is used.

Doesn't that contradict your reply for my initial first question?

[quote userid="6207" url="~/f/nordic-q-a/114001/clarifications-on-errata-20-rtc-register-values-are-invalid/498803"]You need apply this workaround everytime you boot/reboot[/quote]

That seems to imply that "idle" could also refer to the time between boot and we use the RTC the first time?

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Susheel Nuguru — Mon, 19 Aug 2024 13:23:33 GMT

[quote user="Emil Lenngren"]What I really meant here was, are we allowed to do other things between these lines so that the NRF_RTC0->TASKS_STOP = 0; is executed some time later?[/quote][quote user="Emil Lenngren"]I guess if we want to use RTC1 as well the correct thing is to simply append NRF_RTC1->TASKS_STOP = 0; at the end[/quote]

Correct.

Right after the LFCLK is started you can just have a dummy read in both the RTCs like below, we just need a dummy read on that register and some traffic on the transport bus with RTC peripheral being the target.

NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
NRF_CLOCK->TASKS_LFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0) {}
NRF_RTC0->TASKS_STOP = 0;
NRF_RTC1->TASKS_STOP = 0;

The above mean that you have applied the workaround for both instances of RTC at startup.

And yes you can have a delay between the LFCLK started and the fourth line, but it might be risky if some other context (with higher interrupt priority) stole the CPU and the new context started using RTC without the workaround being complete. This is less likely scenario, but a possibility that cannot be ignored in firmware design.

[quote user="Emil Lenngren"]. The busy-loop maxes the CPU. Will the workaround work as well if we set up an interrupt for LFCLKSTARTED and wait for that interrupt to be triggered instead, putting the CPU to sleep in the meantime? That will result in that the TASKS_STOP = 0; line will be executed a few microseconds later, since it takes some time for the CPU to wake up.[/quote]

This will work aswell as long as you make sure that from the time the RTC interrupt is triggered in hardware to the time RTC ISR is called, the CPU will not execute any other higher priority context where it will either

do something that in turns disable the LFCLK or
try to use the RTC without the workaround is not completed.

[quote user="Emil Lenngren"]2. Is this workaround already implemented in nRF Connect SDK / nrfx / nRF5 SDK? I tried to do a fulltext seach on "TASKS_STOP = 0" but didn't find anything relevant. I also tried looking[/quote]

This is excellent question, you are right. The SDK does not seem to be applying this workaround both in nRF5SDK and in nrF Connect SDK. I think that the condition where RTC is idle is never reached the way rtc drivers and libraries are written. That means that the drivers and libraries make sure that from the time RTC is initialized, there is no instance where it gets to IDLE state.

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Emil Lenngren — Mon, 19 Aug 2024 12:39:53 GMT

Thanks for the extremely fast and detailed response!

[quote userid="6207" url="~/f/nordic-q-a/114001/clarifications-on-errata-20-rtc-register-values-are-invalid/498803"]

Can an arbitrary amount of time pass between line 3 and 4?

Depends on the clock used, this time should be fixed per chip/clock configuration. It can vary from one chip to the other in a cycle or two difference.

[/quote]

What I really meant here was, are we allowed to do other things between these lines so that the NRF_RTC0->TASKS_STOP = 0; is executed some time later? Otherwise applying the same workaround for both RTC0 and RTC1 would be impossible (since that would require a re-start of LFCLK if we literally copy-paste the code twice for both RTC0 and RTC1). I guess if we want to use RTC1 as well the correct thing is to simply append NRF_RTC1->TASKS_STOP = 0; at the end.

Some follow-up questions:

1. The busy-loop maxes the CPU. Will the workaround work as well if we set up an interrupt for LFCLKSTARTED and wait for that interrupt to be triggered instead, putting the CPU to sleep in the meantime? That will result in that the TASKS_STOP = 0; line will be executed a few microseconds later, since it takes some time for the CPU to wake up.

2. Is this workaround already implemented in nRF Connect SDK / nrfx / nRF5 SDK? I tried to do a fulltext seach on "TASKS_STOP = 0" but didn't find anything relevant. I also tried looking in https://github.com/NordicSemiconductor/nrfx/blob/master/haly/nrfy_rtc.h as well as the older app_timer.c in nRF5 SDK but didn't find anything there either. Since the errata text is really vague on why/how the workaround code works or what the key instructions are making it work, it's difficult to know if the workaround can be fulfilled in some other way apart from the exact instruction sequence supplied.

From your description "We need to have a dummy access to the RTC and writing 0 to that register does nothing but accesses the module clearly poking power management of the device to tell it to activate the resources needed by RTC." it seems the key here in the workaround is to write anything to the RTC while LFCLK is running to "poke" the power management to activate the resources needed by RTC. Otherwise reading some register can return garbage since the RTC at that point does not have the resources needed enabled.

RE: Clarifications on errata "[20] RTC: Register values are invalid"

Susheel Nuguru — Mon, 19 Aug 2024 11:10:15 GMT

Hi Emil,

You need apply this workaround everytime you boot/reboot or whenever you have forced the LFCLK to stop and start again. That means that as long as the LF-clock is running, the power domains in which the RTCs reside is never switched off and the reads will return correct results.

[quote user=""]Can an arbitrary amount of time pass between line 3 and 4?[/quote]

Depends on the clock used, this time should be fixed per chip/clock configuration. It can vary from one chip to the other in a cycle or two difference.

[quote user=""]Can line 4 (TASKS_STOP) be reordered, i.e. be executed before the LFCLK is started instead, or while it is being started (e.g. if using LFXO as source, it is ok to run line 4 once LFCLKSTAT says running, e.g. before SRC has switched from RC to LFXO)?[/quote]

We do not know, the workaround we provided have been tested. Reordering is not recommended or suggested.

[quote user=""]What "configuration" registers are affected? The only configuration register I see present on the RTC peripheral is the PRESCALER. Does this mean as long as I only write to this register and never read from it, I can ignore this errata?[/quote]

Does not matter, we should assume all registers are effected.

[quote user=""]Is it a typo that 0 should be written to TASKS_STOP? According to the PS only 1 is a valid value to write to the TASKS_STOP register.[/quote]

We need to have a dummy access to the RTC and writing 0 to that register does nothing but accesses the module clearly poking power management of the device to tell it to activate the resources needed by RTC.

[quote user=""]Any code that can reproduce the issue? I cannot reproduce the issue no matter what I've tried so far.[/quote]

Might be that this is very timing related effecting some chips and not all. Best is to not take the risk and apply this workraound at the system startup.