Inaccurate synthesized LF clock

[tim-remoticom]

Hi,

During the validation of our device, we found that the RTC (synthesized from HFCLK) was quite a bit off. Instead of the expected 32.768kHz, we measured 33.047kHz. 

Do you know if we made a mistake somewhere in our tests or RTC configurations?

Hardware:

• MCU: nRF52833 QDAAA0
• HFCLK: External 32MHz clock, tolerance: 10ppm, stability: 15ppm
• LFCLK: Synthesized from HF clock

Firmware:

Connect RTC to GPIOTE output with PPI. On every RTC tick, toggle a GPIO. 

• NCS version: V2.1.0
• RTC settings:
  • RTC inst: RTC2
  • RTC configs: default config (pre-scaler: 0, reliable: false)
  • Frequency: 32768
• GPIOTE setting
  • Pin: 1.09
  • Drive: H0H1
  • Input connect: disconnect
  • pull: no-pull
• Relevant setting:
  
  • CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

Test setup:

The device toggles its pin every RTC pin, which creates a square wave with a frequency of LFCLK/2 (target: 16.384kHz). A frequency counter measures this signal for one hour. The frequency of the RTC is double the measured frequency.

Test result:

We measured a frequency of 16.5237 kHz, which means that the RTC has a frequency of 33.0474kHz. The frequency deviation from this signal is 297.4Hz or 8527ppm. This deviation is much higher than expected.

• Do you know what could have caused this issue?
  
• Did we make a mistake in our LFCLK settings?
• Did we make a mistake in our test?

With kind regards,

Tim

[Vidar Berg]

Hello Tim,

Your test results indicates that the 32.768 kHz synthesized from HFCLK (LFSYNT) may be running off of the less accurate HFINT HFCLK source, and not the crystal oscillator (HFXO). Or have you confirmed that the crystal oscillator is enabled?

There is no kconfig symbol to force on the HFXO oscillator on startup, but you can use the snippet below to start it from main().

void main(void)
{
	NRF_CLOCK->TASKS_HFCLKSTART = 1;
	while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) {
	};
	...

Best regards,

Vidar

[tim-remoticom]

Hi Vidar,

Thank you for your reply.

I think this solved it. I compared the two versions (the one with and without your patch) with an oscilloscope. The version with your patch had greatly improved frequency stability, and the frequency was much closer to the targeted 32.768kHz. But I have to wait till Monday to get the test result from our test engineers. I will share the test results then.

Enjoy your weekend!

Kind regards,

Tim

[Vidar Berg]

Thanks. I hope the new test with HFXO went well.

Kind regards,

Vidar

[tim-remoticom]

Hi Vidar,

I just got the test results back.

We measured over a full hour with a frequency counter. And we measured a frequency of 32.76831kHz for the LFCLK. This frequency has a deviation of 0.305Hz or 9.34ppm (a massive improvement over the first test).

But I was surprised that the HFXO would not automatically boot. Is this also the case for the samples on the nRF52833DK, or do these samples use the HFINT? 

Kind regards,

Tim

[Vidar Berg]

Hi Tim,

Yes, that is an massive improvement. Thanks for reporting back the results.

tim-remoticom said:

But I was surprised that the HFXO would not automatically boot. Is this also the case for the samples on the nRF52833DK, or do these samples use the HFINT? 

The device will always boot with the HFINT source, and it is then up to the application to switch to the HFXO if it needs the higher accuracy. The Softdevice, will for instance start the HFXO prior to operating the RADIO and release it afterwards to lower the power consumption (unless the app has requested the HFXO to be always on).

The benefit of using the HFINT is that it as a short startup up time compare to the crystal oscillator and it can be turned of in System ON mode (idle).

Bluetooth Low Energy power profiles

Kind regards,

Vidar

[tim-remoticom]

Hi Vidar,

In our application, we use Bluetooth (mesh). This is a different application than used in this issue (the application used in this issue is only to validate our hardware).

How can the application ensure (or request) that HFXO is always on? Does the snippet you shared ensure this, or is there a Softdevice API or function to do this?

Power consumption is not an issue for us (our devices are powered).

Kind regards,

Tim

[Vidar Berg]

Hi,

tim-remoticom said:

How can the application ensure (or request) that HFXO is always on? Does the snippet you shared ensure this, or is there a Softdevice API or function to do this?

Yes, if you call it before the softdevice controller is enabled through bt_enable() (the controller will prevent application from accessing the CLOCK peripheral when enabled).

The mpsl clock API does not have this limitation: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/mpsl/doc/api.html#c.mpsl_clock_hfclk_request

Example using the MPSL API:

static void hfxo_callback(void)
{
	printk("HFXO is running\n");
}

void main(void)
{
	int err;

	err = mpsl_clock_hfclk_request(hfxo_callback);
	if (err) {
		printk("mpsl_clock_hfclk_request() returned %d\n", err);
	}

Kind regards,

Vidar