nRF52840 slow boot and delayed BLE start when LFCLK is external square wave or RC

[JACK0]

We have designed two custom boards based on the nRF52840.

Board #1 (Demo board)
This board works correctly. It uses a standard 32.768 kHz passive crystal connected to XL1/XL2.

Board #2 (EV board)
This board does not boot reliably. The main hardware difference is the LFCLK source:
instead of a 32.768 kHz crystal, we feed a full-swing 32.768 kHz square wave generated by an external RTC IC into XL1, while XL2 is tied to GND.

Other differences between the boards are only peripherals and should not affect clocking.

Observed behavior

When we flash the same firmware (from the working demo board) into the EV board:

• The system does not boot immediately

• The 32 MHz crystal (HFXO) attempts to start several times

• We can observe short bursts of 32 MHz oscillation on a scope

• Each attempt stops again

• After roughly ~10–25 seconds, the system finally starts and then works normally

Zephyr configuration (external 32 kHz square wave)

We attempted to configure Zephyr to use an external full-swing clock:

CONFIG_CLOCK_CONTROL=y
CONFIG_CLOCK_CONTROL_NRF=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING=y

We tried several combinations of LFCLK configurations but the behavior remained the same.

Questions:

1. For a rail-to-rail 32.768 kHz clock applied to XL1, what is the correct Zephyr/NCS configuration?

2. Is it necessary to manually start the HFXO in this case?

3. Is feeding a square wave into XL1 (with XL2 grounded) a supported and recommended hardware configuration for BLE applications?

Using internal RC instead

We then removed the external clock and configured LFCLK to internal RC:

CONFIG_CLOCK_CONTROL=y
CONFIG_CLOCK_CONTROL_NRF=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32RC_RC_CALIBRATION=y

With this configuration:

• The firmware runs correctly

• BLE works

• All peripherals function

However, the system boot is very slow (~4 seconds before BLE advertising appears).

Question:
Why does boot time become so long when using the internal RC oscillator?

We are trying to determine whether:

• the external square-wave LFCLK hardware approach is valid, or

• a passive 32.768 kHz crystal is strictly required for reliable BLE startup.

Any guidance would be greatly appreciated.

Jack

[Simonr]

Hi Jack

Rail-to-rail questions:

1. On the nRF52 series CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING=y should be sufficient. Can you share more details on what SDK version you're working on and what application is running. Are you also using MCUBoot for instance? If so you also need to set this in the MCUBoot config file.
2. No, it should not be necessary to start the HF clock manually. Can you share some details about the RTC IC that delivers the full swing 32.768kHz square wave?
3. Yes, a rail-to-rail clock signal applied to the XL1 pin. The XL2 pin shall then be grounded or left unconnected. It's not the most common use case, but should be within specified behavior.

The internal RC oscillator shouldn't cause the boot time to increase this much. Can you share some more information on what nRF Connect SDK version you're working on. The configs seem to be set correctly.

Best regards,

Simon