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]

When you're using the nRF Connect SDK, configuring the low-frequency clock (LFCLK) to use an external crystal oscillator is done with settings like:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=y

These settings tell the system to use the external crystal oscillator for the LFCLK. But if your board doesn’t have an external LFCLK crystal, you might see some unexpected behavior. The way the nRF Connect SDK manages this is a bit different from the older nRF5 SDK.

With the above configuration, the SDK tries to start the external crystal oscillator. If it doesn’t detect a crystal (such as on a board without one), it’s likely the SDK will automatically switch to the internal RC oscillator. However, you may still see values in the LFCLKSTAT register that suggest it’s using the external crystal (like 0x00010001), even though it’s actually using the internal RC oscillator instead.

nRF5 SDK: In the nRF5 SDK, if you configure the LFCLK to use a crystal that isn’t present, the SoftDevice initialization fails with an error (NRF_ERROR_INVALID_PARAM). This error gives immediate feedback, showing that the configuration doesn’t match the hardware.

nRF Connect SDK: Using Zephyr’s clock management system, the nRF Connect SDK is more flexible in this situation. Instead of raising an error, it falls back to using the internal RC oscillator if no external clock is detected. This lets the LFCLK source keep running, even though it’s using the internal oscillator.

One main reason for this difference is how the Zephyr clock management subsystem in the nRF Connect SDK handles things. The nRF5 SDK, being more of a bare-metal solution, explicitly checks for an external crystal if configured as the LFCLK source and stops if it isn’t found. In contrast, the nRF Connect SDK, with Zephyr’s clock management, assumes a more flexible approach. Without an external crystal, it can automatically switch to the internal RC oscillator to continue running without errors. As a result, you might still see the LFCLK source as “active,” even though it’s running off a different oscillator.

In essence, Zephyr’s clock management in the nRF Connect SDK takes a “graceful fallback” approach, which differs from the nRF5 SDK’s strict, bare-metal checks. This makes for smoother operation when external components aren’t available, though it may lead to different status indicators than you’d expect based on the nRF5 SDK’s behavior.

[ntennies]

Susheel, thank you for your response. I certainly can understand that nRF Connect SDK might take a more graceful fallback approach than the nRF5 SDK in this case. But this does not entirely answer my question, which also has to do with the behavior of hardware in this case.

The LFCLKSTAT register is a read-only register controlled by MCU hardware, so its underlying behavior should not be affected by a change in firmware, and obviously firmware cannot force arbitrary bits to be set in that register.

As I mention above, if I initialize the LFCLK for external oscillator (XTAL) on a board without one using the code shown above, but wait 500ms instead of looping forever, LFCLKSTAT ends up being 0x00010000, so LFCLKSTAT.STATE shows "Running" and LFCLKSTAT.SRC shows "RC". It would appear that this represents a "graceful fallback" at the hardware level; LFCLKSTAT is telling us that the LFCLK is "Running" but that it has fallen back on "RC" because the requested "XTAL" is not available.

So, my  questions are:

1) How is it possible LFCLKSTAT could ever be 0x00010001 on the same board, since that value is produced by hardware? Given what I just stated, what inputs to the CLOCK controller is the nRF Connect SDK performing to produce such a value on LFCLKSTAT, somehow forcing LFCLKSTAT.SRC to 1 (XTAL) even though the board lacks one?

2) If the nRF Connect SDK was actually "falling back to using the internal RC oscillator if no external clock is detected" as you say — in other words, if after a timeout attempting to start LFCLK on XTAL, it instead started LFCLK on RC — wouldn't we still expect to see LFCLKSTAT report 0x00010000 in this case? How does LFCLKSTAT = 0x00010001 represent the outcome of a graceful fallback to RC by firmware?

3) Given that my code above is showing that 0x00010000 is the normal LFCLKSTAT state when an attempt is made to start it on XTAL on a board without one, doesn't having LFCLKSTAT show 0x00010001 on a board with no XTAL indicate that there's something wrong with the state of the hardware, that the read-only LFCLKSTAT register is telling us that it thinks LFCLK is running on XTAL not on RC, even though no XTAL is present?

[Susheel Nuguru]

Yes, you are right, LFCLKSTAT register should not be giving 0x00010001 if there is not external crystal. If you are absolutely sure that there is no XTAL, then I can try to replicate this with minimalistic code in nrf connect sdk. Can you please give me the laser marking on your chip so that I get the build code for it and understand which batch of production those are? I can then try to do a test on something with the batch close to that.

[ntennies]

Susheel, unfortunately this particular board is based on the Fanstel BC805M-V1 module, so I can't actually see the nRF52805 (the module PCB is covered in a metal enclosure with only the antenna sticking out), and so I can't read the laser marking on the MCU. There's no obvious serial number on the module so I'm doubting Fanstel would be able to provide that information.  is there any other way we can get this information, without destructively tearing apart the module? 

Regarding the presence of the XTAL, the Fanstel BC805M-V1 does not include a 32KHz oscillator, but it does bring out P0.00 and P0.01, so as I mentioned, I don't have a schematic for the carrier board, so I can't explicitly rule out the present of an XTAL on that board. But if the XTAL was included, lfclock_init() above shouldn't be hanging when attempting to start LFCLK with XTAL, and nrf_sdh_enable_request() shouldn't be returning NRF_ERROR_INVALID_PARAM) when NRF_SDH_CLOCK_LF_SRC is defined as 1., which is what I'm seeing.

[ntennies]

Susheel, I wanted to provide a few more pieces of information to close the loop on this from my side. As I mentioned in my original question, this question about the nRF52805 LFCLK behavior came up when I was debugging some very weird behavior with a custom nRF52810 board, which I thought might stem from the fact that this nRF52810 board also lacked an external LFCLK oscillator but was configured in Zephyr to use one.

I just got that nRF52810 board back so I could finish testing and found some things I think Nordic really needs to explore.

1) When I create a build configuration for the nRF52810 that indicates external LFCLK oscillator should be used, and then output the LFCLK regs at the top of the main() when running under Zephyr, I get the same invalid value on LFCLKSTAT (0x00010001) on our nRF52810 board that I reported on the nRF52805! I think that proves that this issue is not tied to a specific batch of nRF52805 processors, but stems from something common to all of these related processor designs.

2) Unlike the nRF52805 board I was using, I do have schematics for this custom nRF52810 board, and it _definitely_ does not have an external LFCLK oscillator, but we're still seeing LFCLKSTAT = 0x00010001.

3) This invalid LFCLKSTAT value — which indicates that the LFCLK is running on an external LFCLK oscillator even though the board lacks one — is arising inside the MPSL LFCLK initialization code. Before that code is called, LFCLKSTAT is zero, after it is called, it is 0x00010001. Of course, since I don't think we have access to the MPSL source, I don't have a way to determine why this is happening on these MCUs.

4) The weird behaviors I was seeing on our custom nRF52810 board are _definitely_ the result of this LFCLK misconfiguration, which means that Zephyr is _not_ gracefully falling back to the internal RC oscillator when it tries to use the external LFCLK oscillator but it is unable to get an LFCLKSTARTED event (again, if this was what what was happening, LFCLKSTAT should be 0x00010000). I think this strongly suggests that the invalid LFCLKSTAT = 0x00010001 we're seeing really does indicate an invalid hardware state that is affecting MCU behavior.

For instance, in our firmware — which is pretty similar to the LED_Button sample —  I'm seeing the board consistently hang when I call settings_subsys_init(), when nrf_flash_sync_exe() tries to take the timeout_sem in line 205 of flash_sync_mpsl.c. If I remove the initialization of the Zephyr settings modules, I get to the point where I start BLE advertising sucessfully, but there's no evidence of advertising packets  being sent from the nRF52810.

However, if I make these change to my prj.conf file, our firmware works fine on our nRF52810 board:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=n

You should be able to reproduce this yourself: I cloned the LED_Button sample for Zephyr, and created a build configuration for the nRFDK_nRF52810 using the prj_minimal.conf file and the Debug optimizations. I then commented out the dk_leds_init() and init_button() calls but to avoid GPIO conflicts on our nRF52810 board but left everything else the same, including the configuration for using the external LFCLK oscillator.

When I run this LBS sample on my nRF52810 board, it consistently hangs in bt_enable(NULL). However, if I switch to the LFCLK RC oscillator in  prj_minimal.conf file by adding the lines above, the LED_Button sample works fine on our nRF52810: