Regarding the MPSL ASSERT: 1, 1519 issue

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Susheel Nuguru — Tue, 27 Jan 2026 11:30:21 GMT

[quote user="Ron Liu"]We therefore suspect that the timeout used to trigger the assertion is effectively 1000 µs instead of the configured CONFIG_MPSL_HFCLK_LATENCY value. We would like the Nordic team to review the MPSL source code to confirm this behavior.[/quote]

I have checked the MPSL code myself and that should not be the case.

One suspect could be that in nrf/subsys/mpsl/init/mpsl_init.c you have this code

#if !defined(CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL)
#if defined(CONFIG_CLOCK_CONTROL_NRF) && DT_NODE_EXISTS(DT_NODELABEL(hfxo))
	mpsl_clock_hfclk_latency_set(z_nrf_clock_bt_ctlr_hf_get_startup_time_us());
#else
	mpsl_clock_hfclk_latency_set(CONFIG_MPSL_HFCLK_LATENCY);
#endif /* CONFIG_CLOCK_CONTROL_NRF && DT_NODE_EXISTS(DT_NODELABEL(hfxo)) */
#endif /* !CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL */

...

If you have a device tree node for hfxo and a startup_time_us, then it seems that it will take that instead of CONFIG_MPSL_HFCLK_LATENCY. Check your finally built zephyr.dts and check if you have some entry there witih hfxo and startup_time_us. I am guessing, most likely you do have some entry there with value less than 1800us.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Ron Liu — Tue, 27 Jan 2026 01:52:27 GMT

After extensive cross-testing, we have concluded that this is not a software logic issue but rather related to the crystal oscillator startup time. The specific problem we need to confirm is as follows:

Currently, we have set CONFIG_MPSL_HFCLK_LATENCY to 1800 µs, while the actual measured crystal oscillator startup time is around 1000 µs. In theory, this configuration should not trigger an assertion; however, in practice, the assertion still occurs.

We therefore suspect that the timeout used to trigger the assertion is effectively 1000 µs instead of the configured CONFIG_MPSL_HFCLK_LATENCY value. We would like the Nordic team to review the MPSL source code to confirm this behavior.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Susheel Nuguru — Mon, 26 Jan 2026 11:23:52 GMT

Hmm, that seems high. Are you sure that your firmware is not disabling global interrupts at any part or time in your code? The assert says that the app somehow kept the CPU for itself a bit longer than it should. Are you using timeslot API? if yes, did you receive MPSL_TIMESLOT_SIGNAL_OVERSTAYED event before the assert?

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Ron Liu — Mon, 26 Jan 2026 09:30:39 GMT

Currently, 3-4 devices have been found to be abnormal, with a probability of about 1 in 20.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Susheel Nuguru — Mon, 26 Jan 2026 09:14:03 GMT

How many devices did you test? I mean I wanted to know the failing rate of the devices. You said two devices see this issue, out of how many?

We might have to do a failure analysis on the failing device if it is only happening on the 2 devices.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Ron Liu — Mon, 26 Jan 2026 08:22:48 GMT

Currently, we have set CONFIG_MPSL_HFCLK_LATENCY to 1800, but the actual measured crystal oscillator time is around 1000 µs. In theory, an assertion should not occur, but in practice, it does. We infer that the time triggering the assertion is 1000 µs instead of CONFIG_MPSL_HFCLK_LATENCY. We need the Nordic team to review the MPSL source code to confirm this.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Susheel Nuguru — Mon, 26 Jan 2026 08:11:59 GMT

Hi Liu,

I am not sure if I understood your statement correctly. You need to set CONFIG_MPSL_HFCLK_LATENCY atleast to 1000 in your project configuration to tell MPSL to wait that time for the crystal startup. What is the value set to it now? If it is less than 1000 for a crystal that takes 1000us in your board, then that might explain the assert.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

sean — Mon, 26 Jan 2026 06:24:57 GMT

Hi，

Ron Liu is our customer，the owner of the problem，please help check.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Ron Liu — Mon, 26 Jan 2026 06:21:18 GMT

Through our experimental verification, the crystal oscillator startup time is fixed at 1000us, rather than CONFIG_MPSL_HFCLK_LATENCY. We need to confirm this.

RE: Regarding the MPSL ASSERT: 1, 1519 issue

Susheel Nuguru — Fri, 23 Jan 2026 11:15:32 GMT

MPSL ASSERT: 1, 1519 in NCS 3.1 happens if HFXO takes too long to wake up.

CONFIG_MPSL_HFCLK_LATENCY should be selected based on PCB design (HFXO model, capacitance, voltage etc). It is possible that the customer need to measure HFXO startup time and change CONFIG_MPSL_HFCLK_LATENCY (or device-tree hfxo,startup-time-us entry) based on the measurement results.

There is a relevant documentation in Kconfig:

https://github.com/nrfconnect/sdk-nrf/blob/v3.1.0/subsys/mpsl/init/Kconfig#L79