nRF52805 LFRC frequency tolerance exceeding ±2% on multiple devices

We are operating the 32.768 kHz low-frequency clock of the nRF52805 using the internal RC oscillator (LFRC).

We measured the LFCLK frequency of 100 devices, and the observed frequency tolerance relative to 32.768 kHz ranged from −0.2% to +2.7%.
As a result, some devices exceeded the ±2% frequency tolerance stated in the datasheet.

This result seems worse than expected based on the datasheet specification.

  • Is this level of frequency tolerance considered normal behavior for the LFRC on the nRF52805?
  • Could this be related to firmware configuration, such as LFRC calibration settings (RC_CTIV / TEMP_CTIV), SoftDevice usage, or clock initialization?
  • Are there any known conditions (temperature, startup behavior, calibration timing, etc.) that could cause the LFRC frequency tolerance to exceed ±2%?

For reference:

  • LFCLK source: LFRC (internal RC oscillator)
  • Measurements were performed under identical conditions for all devices.
  • SoftDevice is used, with LFRC calibration enabled.

Any guidance on expected LFRC frequency tolerance, recommended settings, or additional checks would be greatly appreciated.

Thank you.

  • Hi

    You're correct, the frequency tolerance should be  ±2% for the LF RC oscillator. What's interesting here is that the range seem to be skewed a bit, since it's barely off on the negative side, and slightly above the expected tolerance on the positive side. If you don't do calibration often enough, then that can be a cause for this to occur. What have you set the calibration settings to in your project? What SDK version and SoftDevice version are you using for development?

    Best regards,

    Simon

  • Hi Simon,

     

    Thank you for your response.

     

    Our development environment and current LFRC calibration settings are as follows:

     

    SDK: nRF5 SDK 17.1.0 

    SoftDevice: s112_nrf52_7.3.0_softdevice 

     

    sdk_config.h:

     

    #define NRFX_CLOCK_CONFIG_LF_SRC              0   // RC

    #define CLOCK_CONFIG_LF_SRC                   0   // RC

    #define NRF_SDH_CLOCK_LF_SRC                  0   // NRF_CLOCK_LF_SRC_RC

    #define NRF_SDH_CLOCK_LF_RC_CTIV              16

    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV          2

    #define NRF_SDH_CLOCK_LF_ACCURACY              1   // NRF_CLOCK_LF_ACCURACY_500_PPM

     

    Could you please let us know if there are any issues with this configuration, or if you would recommend different calibration settings to ensure the LFRC frequency stays within the ±2% specification?

     

    Best regards,

  • Hi

    This should be sufficient calibration intervals in most cases. Are there a lot of temperature changes in the environment you're testing in, or is it stable and around room temperature? Do all the 100 devices go outside the specifications, or only some of them? Also, can you share some more information on how you measure the frequency tolerance on your end?

    Best regards,

    Simon

  • Hi

    The evaluation environment is indoors, and temperature variations are small and stable around room temperature.

    Out of the 100 devices measured, 15 devices exceeded the ±2% specification.
    The frequency distribution is approximately normal, with a mean value of +1.2%, and the deviation is biased toward the positive side overall, rather than being centered around 0%.

    The measurement equipment used has ppm-order accuracy, and we verified the measurement setup using a TCXO reference; the observed error of the test equipment itself was very small and can be considered negligible.

    Using the code shown below, a 16.384 kHz clock signal is generated on a GPIO pin, and the frequency is measured using a multimeter.

    Below is the clock output control code used for generating the LFCLK output:

     

    // Enable XTAL/2Hz clock output to GPIO.

    NRF_RTC0->PRESCALER = PRESCALER_FOR_CHK_XTAL;

    NRF_RTC0->EVTEN = (RTC_EVTENSET_TICK_Msk); /* event on TICK */

     

    // configure GPIOTE

    NRF_GPIOTE->CONFIG[0] =

    ((GPIOTE_CONFIG_MODE_Task << GPIOTE_CONFIG_MODE_Pos)

    | (GPIO_LFCLK_OUTPUT << GPIOTE_CONFIG_PSEL_Pos)

    | (GPIOTE_CONFIG_POLARITY_Toggle << GPIOTE_CONFIG_POLARITY_Pos))

    | (0 << GPIOTE_CONFIG_OUTINIT_Pos);

     

    // configure PPI

    NRF_PPI->CH[0].EEP = (uint32_t)(&NRF_RTC0->EVENTS_TICK);

    NRF_PPI->CH[0].TEP = (uint32_t)(&NRF_GPIOTE->TASKS_OUT[0]);

    NRF_PPI->CHENSET = PPI_CHENCLR_CH0_Msk;

     

    // Clock ON

    NRF_RTC0->TASKS_START = 1;

     

    Please let us know if there are any concerns with this measurement approach or configuration, or if additional information is required.

    Best regards,

  • Hi

    Okay, I discussed this with a colleague, and one thing this could be due to is if the SoftDevice isn't enabled to calibrate the LFRC at all. It seems like you have programmed the SoftDevice, but we don't see any mention of where it is enabled in your application. Can you show us how SoftDevice is enabled on your end?

    Best regards,

    Simon

Related