nRF5340 with DS3231 as LXFO

RE: nRF5340 with DS3231 as LXFO

reavertm — Wed, 15 Jul 2026 20:49:16 GMT

Sorry for long reply. Works as expected indeed. Thanks.

RE: nRF5340 with DS3231 as LXFO

Vidar Berg — Mon, 01 Jun 2026 12:40:19 GMT

I would expect the peaks to be at VDD. Are you able to swap out the 100K resistor with a smaller value (10 k or 4.7 kOhm) and see if the signal improves with a stronger pull up resistor? It also looks like the oscilloscope's sample rate may be too low to accurately capture the waveform.

[quote user="reavertm"]"If two instances of the LFCLK control system request different LFCLK sources, the power and clock subsystem will secure that the most accurate of the requested LFCLK sources is selected." doesn't work?[/quote]

Yes, LFXO will be used by the system when active. But you should avoid selecting different clock sources in your project. One problem with selecting the LFRC source is that this will enable periodic clock calibration against HFXO.

RE: nRF5340 with DS3231 as LXFO

reavertm — Mon, 01 Jun 2026 05:29:34 GMT

It somewhat works but also doesn't.

I want my bootloaders to use RC (more compatible, and there are no timestamps printed there so I don't care), so I left mcuboot and b0n to use internal load capacitor and RC clock in config. They also never touch my DS3231 RTC over I2C.

I am only setting BYPASS=1 in SYS_INIT and selecting XTAL of my main app on App core. I assumed ipc_radio will get it anyway, per [1]:

If two instances of the LFCLK control system request different LFCLK sources, the power and clock subsystem will secure that the most accurate of the requested LFCLK sources is selected.

My main app on boot reads RTC from DS3221 over I2C and immediately calls clock_settime(CLOCK_REALTIME, ..).

And when I print clock control registers in my main app, I get:

BYPASS=1 LFCLKSRC=2 LFCLKRUN=1 LFCLKSRCCOPY=2 LFCLKSTAT={SRC=2 ALWAYSRUNNING=0 STATE=1}

So everything looks fine on app core, after a week system time drift is within 1s.

But BLE (that is running on ipc_radio) silently stops working or at least it appeas so as I cannot connect anymore with paired BLE client. I don't have debug logs from Net core unfortunately so can only guess so far.

When I trigger some BLE HCI command (in ex by triggering pairing, so reconfiguration of sending advertisement packets with different allowlist), app core crashes with:

2026-05-31T16:00:46.184Z <dbg> [sysworkq] main: stop_advertising_work_handler:
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/external/zephyr/subsys/bluetooth/host/hci_core.c:504
Controller unresponsive, command opcode 0x200a timeout with err -11

Would that be because Net core uses different LFXO (RC) and somehow got de-synchronized with App over time?

I did not configure ipc_radio to request LFXO and if cores got indeed desynchronized then maybe:

"If two instances of the LFCLK control system request different LFCLK sources, the power and clock subsystem will secure that the most accurate of the requested LFCLK sources is selected." doesn't work?

Or there is race condition because maybe ipc_radio is booted first (because b0n booted it sooner than mcuboot booted main app), ipc_radio requested LFCLK, got RC (because higher accuracy LFXO was not available yet), then main app booted and requested LCFLK, got LFXO, but it happened too late for ipc_radio to pick it up? I wil test this but would like to know how it's supposed to work because reference manual is not fully clear on this, in ex whether cores can run on different low frequency clocks.

Also, what is expected voltage level on signal on X1 vs VDD in case of rail-to-rail external LFXO and expected signal shape for X1 in such configurtation on nRF5340 ?

My nRF5340 runs on VDD=3.3, 100k pull-up resistor on X1 brings down external 32KHz down to 1,64V. It is also a pulse, not square. Does it need to be square? Oscilloscope output below:sigmalabsspace-my.sharepoint.com/.../IQD6W31HrNnIQa_RitHxun7gARYtonXIpmae9V0hVFD23co

LLM in typical overly confident manner says that resistor is too strong and I should get it closer to 3.3V and it's root cause for BLE not working. But it sounds like nonsense to me, if I indeed have "significant parasitic capacitance" on X1, and external LFXO is not interpreted correctly by nRF, it would fail to keep system time stable on App core all the same - I think - but that one appears to work fine.

Thanks in advance!

1. docs.nordicsemi.com/.../clock.html

RE: nRF5340 with DS3231 as LXFO

Vidar Berg — Wed, 20 May 2026 07:24:04 GMT

Hello,

The clock driver does not support external clock sources, but you should be able to work around this by setting the bypass register early on boot before the clock driver init as Bendik suggested in the post you linked (Clock Control Configuration Confirmation).

I suggest you start with something simple like the "Hello World" sample first to verify that you are able to run it with your external clock source (CLOCK_CONTROL_NRF_K32SRC_XTAL must be set to =y). Since the system timer used by Zephyr relies on this clock source, the program will not reach main() unless the LF clock was started (this assumes the default CONFIG_SYSTEM_CLOCK_WAIT_FOR_STABILITY is selected).

[quote user=""]

how should devicetree and config look like for RC bypass to work?

I suppose I need

[/quote]

Yes, you should select "external" for the load caps.

Best regards,

Vidar