Weird LFCLK Behavior With nRF Connect SDK v2.6.1 On nRF52805 Without External LFCLK Oscillator

[ntennies]

I ran across this issue while troubleshooting a separate issue, in which I have an nRF52810-based board with no external LFCLK oscillator that is rock-solid with nRF5 SDK but is behaving weirdly with nRF Connect SDK, and I suspected this was due to having misconfigured the SDK to specify the use of the external LFCLK oscillator . While looking at this, I tried the same code and configuration on an nRF52805-based board which works fine with the nRF Connect SDK, but which I think also lacks an external LFCLK oscillator (for reasons surpassing understanding, I haven't been given a schematic for this nRF52805-based board).

Here's what's weird: with the nRF Connect SDK LFCLK configuration like this:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=y

I see the following on the nRF52805 LFCLK regs when I check them at the top of main():

LFCLKSRC 0x00000001 LFCLKSTAT 0x00010001 LFCLKRUN 0x00000001 CTIV 0x00000000

I understand why LFCLKSRC is 1, but if there's no external LFCLK oscillator on this nRF52805 board, how on Earth is LFCLKSTAT is 0x00010001? It seems like that should only be possible of there is an external LFCLK oscillator, right?

But the problem is that, if I check this with nRF5 SDK firmware on the same board, it consistently shows there is is no external LFCLK oscillator. For instance, if I configure the nRF5 SDK using:

#define NRF_SDH_CLOCK_LF_SRC 0

then everything works fine (SoftDevice initializes without problem, etc). But if I configure the nRF5 SDK using:

#define NRF_SDH_CLOCK_LF_SRC 1

I get an error 7 (NRF_ERROR_INVALID_PARAM) returned from nrf_sdh_enable_request(). And if, before I make that call, I manually configure and enable the LFCLK on the nRF52805 using this code from Errata 3.2 [20], it never exits the loop checking EVENTS_LFCLKSTARTED:

static void lfclock_init(void)
{

NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
NRF_CLOCK->LFCLKSRC = 1;
NRF_CLOCK->TASKS_LFCLKSTART = 1;

while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0)
{
}

NRF_RTC0->TASKS_STOP = 0;
NRF_RTC1->TASKS_STOP = 0;

}

Finally, if I replace the wait loop in lfclock_init() above with an nrf_delay_us(500000),and then check the LFCLK registers, they are set exactly like you'd expect if there was no external LFCLK oscillator (they show the LFCLK is running, but not from the external oscillator):

LFCLKSRC 0x00000001 LFCLKSTAT 0x00010000 LFCLKRUN 0x00000001 CTIV 0x00000000

So that's my question. Why does nRF5 SDK and the LFCLK registers themselves tell me it is impossible to configure an external LFCLK oscillator on this nRF52805-based board, but when I run nRF Connect SDK firmware configured for external LFCLK oscillator on the same board, LFCLKSTAT is 0x00010001, which clearly indicates that it is running on an external LFCLK oscillator?

What am I missing here?

Thank you!

[Susheel Nuguru]

Nathan,

Thanks for all that info. It seems very possible that there is either some bug in MPSL initialization code or something wrong with the hardware stat register. Either way I need to recreate this issue on my desk before I can poke the hardware engineers. Since you are so confident that this issue lies on the nRF hardware side and since you have done quite a bit of debugging attempts yourself, I will try to replicate this on my end. I need to modify the DK I have to remove the XTAL. It might take some time. Meanwhile, assume that this is a hardware bug and try to have a temporary workaround for this (by adding delay instead of relying on the LFCLK stat register) so that you can proceed your development for now. 

I will dedicate some time to debug this at my end most likely early next week.

[ntennies]

Susheel,

Thank you for the update. So I'm in good shape at this point, since I've identified that the weird behavior on our nRF52810 was due to this LFCLK configuration mismatch, and our board is working well now that I've fixed it. I'll leave this ticket open so you can report what you found, or if you have questions fo rme, but I just wanted to be clear that this is no longer urgent for our project, but obviously is something that should be hunted down and resolved.

One thing that I think is important is that this LFCLK fallback be documented for SDK users, because it certainly wasn't clear to me how the SDK was handling this, but also because if there's a manufacturing issue that is preventing XTAL from working, simply falling back to RC may not be the correct behavior for every product (e.g. for products that need a high degree of RTC accuracy).

As a result, I think it's important to have a way for SDK users to either be able to control application of the fallback _or_ at least to be able to detect that it has happened (I guess I'm doubting most devs even know to look for it at this point). Once the fallback is actually configuring the LFCLK to use RC, LFCLKSTAT should be 0x00010000 if the fallback was used, and an SDK user could check that to see if an expected XTAL was present. Is there an SDK function that provides LFCLK status?

One other thing related to the automatic fallback: does the MPSL automatically change the accuracy from whatever is specified for the XTAL to 500 PPM for the RC when the fallback occurs? It seems like it would need to, right? Again, I think that should be documented as well.

[Susheel Nuguru]

sorry for the late reply Nathan, And thanks for sharing that with me.

ntennies said:

As a result, I think it's important to have a way for SDK users to either be able to control application of the fallback _or_ at least to be able to detect that it has happened (I guess I'm doubting most devs even know to look for it at this point). Once the fallback is actually configuring the LFCLK to use RC, LFCLKSTAT should be 0x00010000 if the fallback was used, and an SDK user could check that to see if an expected XTAL was present. Is there an SDK function that provides LFCLK status?

I am 100% with you, if there is infact the difference in how this is handled, this should be documented from our end. We are a bit short of 52810 DK and hence resisting a bit to make changes to it on the hardware to cutoff the XTAL to test this. I will have to make a timeboxed testing on this, and will report my findings to the devteam and also here.

ntennies said:

One other thing related to the automatic fallback: does the MPSL automatically change the accuracy from whatever is specified for the XTAL to 500 PPM for the RC when the fallback occurs? It seems like it would need to, right? Again, I think that should be documented as well.

I am not 100% sure that it does, that is also something I need to dive into the code and see.