nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

RE: nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

DhruvitDV2707 — Tue, 25 Nov 2025 08:21:37 GMT

Hi,

Thank you so much for all the support.

The MPSL assertion 1519 is resolved.

The Ezurio BL54L15 DK (Part Number: 453-00001-K1) has different crystal load capacitor requirements than Nordic's reference design.

# Root Cause:

The board uses external load capacitors on the PCB. Building with Nordic's board target (nrf54l15dk/nrf54l15/cpuapp) applies internal load capacitor values (HFXO: 15pF, LFXO: 17pF) on top of the external ones, causing over-capacitance that prevents reliable crystal startup. This led to MPSL assertion 1519 when the radio attempted to use the HFXO at ~5 seconds.

# Three changes fixed it:

1. Device Tree Overlay:

Reduced Crystal Load Capacitance
- HFXO Configuration - Reduced from 15pF to 10pF
- LFXO Configuration - Reduced from 17pF to 12.5pF

2. Programmatic MPSL HFCLK Latency Setting

MPSL HFCLK latency set to 20ms for Ezurio BL54L15 DK.

3. MPSL HFCLK Latency (Kconfig)

15ms - setting.

Thanks again, Einar, for your quick support.

I am resolving the issue here.

RE: nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

DhruvitDV2707 — Tue, 25 Nov 2025 07:09:17 GMT

Hi,

On a new system, I installed the ncs3.1.1 on VS Code, and tried testing the existing peripheral_uart sample. I ensured that I do not make any manual changes to the SDK.

However, I am still facing the same results.

RE: nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

Einar Thorsrud — Mon, 24 Nov 2025 08:53:29 GMT

Hi,

That was a large diff. Can you download the SDK again to get a fresh start and test the peripheral_uart sample again and see how it behaves then?

No jumpers are needed on the DK (other than not removing the jumper on the VDD current measurement port, that needs to sit between the two left most pins, as it did when the DK was new.)

RE: nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

DhruvitDV2707 — Mon, 24 Nov 2025 08:27:08 GMT

devzone.nordicsemi.com/.../sdk_5F00_diff.txt

Hi,

[quote userid="7377" url="~/f/nordic-q-a/125752/nrf54l15-mpsl-assert-1-1519-at-5-seconds---all-software-fixes-failed/555144"]Can you share the output from west status or alternatively revert everythign (or check out a new SDK if that is easier)?[/quote]

-> I have attached a file for your reference.

[quote userid="7377" url="~/f/nordic-q-a/125752/nrf54l15-mpsl-assert-1-1519-at-5-seconds---all-software-fixes-failed/555144"]Or did you have something else in mind?[/quote]

-> I was asking for the generic test. For the existing sample application, peripheral_uart as well, is there any jumper change required on the DK?

RE: nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

Einar Thorsrud — Mon, 24 Nov 2025 08:10:59 GMT

Hi,

[quote user="DhruvitDV2707"]-> I checked with "west status" and there are changes displaying. But I suppose those are made by the VS Code or at the time of build. [/quote]

"west status" only lists files that are checked in, adding new files (like the build folder) should not show up. Can you share the output from west status or alternatively revert everythign (or check out a new SDK if that is easier)?

[quote user="DhruvitDV2707"]

-> I tested the existing and unmodified "peripheral_uart" example application. And I am observing the same behavior on that example. The assertion happens after 5 seconds.

[/quote]

I see. Then I suspect either a firmware issue if there are accidental changes in the SDK code that cold be related, or faulty/damaged DK hardware.

[quote user="DhruvitDV2707"]Are there any jumper settings that I need to update on the DK?[/quote]

No changes are needed for the HFXO test code. Or did you have something else in mind?

RE: nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

DhruvitDV2707 — Mon, 24 Nov 2025 05:48:10 GMT

Hi,

Thank you for your quick reply.

[quote userid="7377" url="~/f/nordic-q-a/125752/nrf54l15-mpsl-assert-1-1519-at-5-seconds---all-software-fixes-failed/555048"]My understanding is that you are testing on the DK?[/quote]

-> Yes, I am working with nRF54L15 DK(Part Number: 453-00001-K1, Product Code: BL54L15).

[quote userid="7377" url="~/f/nordic-q-a/125752/nrf54l15-mpsl-assert-1-1519-at-5-seconds---all-software-fixes-failed/555048"]Have you made any changes to the DK hardware?[/quote]

-> None. It's as it is.

[quote userid="7377" url="~/f/nordic-q-a/125752/nrf54l15-mpsl-assert-1-1519-at-5-seconds---all-software-fixes-failed/555048"]Have you made any changes to the SDK itself? (You can check for any changes using "west status")[/quote]

-> I checked with "west status" and there are changes displaying. But I suppose those are made by the VS Code or at the time of build.

However, I have not manually modified anything in the SDK.

[quote userid="7377" url="~/f/nordic-q-a/125752/nrf54l15-mpsl-assert-1-1519-at-5-seconds---all-software-fixes-failed/555048"]If you test with an unmodified example application (for instance Peripheral LBS). Does the assert happen then as well?[/quote]

-> I tested the existing and unmodified "peripheral_uart" example application. And I am observing the same behavior on that example. The assertion happens after 5 seconds.

"""
*** Booting My Application v3.1.1-e2a97fe2578a ***
*** Using nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
Starting Nordic UART service sample
ASSERTION FAIL [0] @ WEST_TOPDIR/nrf/subsys/mpsl/init/mpsl_init.c:307
MPSL ASSERT: 1, 1519
"""

[quote userid="7377" url="~/f/nordic-q-a/125752/nrf54l15-mpsl-assert-1-1519-at-5-seconds---all-software-fixes-failed/555048"] If you measure he duration of the last pulse with a logic analyzer, that shows the HFXO startup time. Does it start at all? And if so, what is the startup time?[/quote]

-> I will get back to you on this after I observe the behavior on the logic analyzer.

Are there any jumper settings that I need to update on the DK?

RE: nRF54L15 MPSL ASSERT: 1, 1519 at ~5 seconds - All software fixes failed

Einar Thorsrud — Fri, 21 Nov 2025 13:06:10 GMT

Hi,

[quote user=""]Could this be a hardware issue with the DK's crystal, or is it purely software?[/quote]

It could be both. The assert indicate problems with starting and tuning the high frequency crystal oscillator (HFXO). This can be due to misconfiguration or due to a HW problem. The first thing I would have suggested is to increase CONFIG_MPSL_HFCLK_LATENCY, but I see you have already done that.

[quote user=""]Are there any DK-specific configuration requirements for nRF54L15 that differ from other nRF54 series?[/quote]

There a significant differences between the nRF54L series and nRF54H series, but as long as you are testing on the DK and building for the DK board files that is handled.

I have some questions in order to understand more.

My understanding is that you are testing on the DK?
Have you made any changes to the DK hardware?
Have you made any changes to the SDK itself? (You can check for any changes using "west status")
If you test with an unmodified example application (for instance Peripheral LBS). Does the assert happen then as well?

It could also be interesting to do a test to check the HFXO startup time using this code snippet (can be copy-pasted into the hello world project or similar). If you measure he duration of the last pulse with a logic analyzer, that shows the HFXO startup time. Does it start at all? And if so, what is the startup time?

#include <stdio.h>
#include <hal/nrf_gpio.h>
#include <zephyr/kernel.h>

#define OUTPUT_PIN NRF_GPIO_PIN_MAP(2,6)

int main(void)
{
	printf("Measuring HFXO startup time on %s\n", CONFIG_BOARD_TARGET);

	// Coinfigure output pin
	nrf_gpio_cfg_output(OUTPUT_PIN);
	nrf_gpio_pin_clear(OUTPUT_PIN);

	// Sleep for a seconds to avoid confusion. Only last pulse on the logic analyzer will then be relevant.
	k_sleep(K_MSEC(1000));

	NRF_CLOCK->EVENTS_XOTUNED = 0;
	nrf_gpio_pin_set(OUTPUT_PIN);
	NRF_CLOCK->TASKS_XOSTART = 1;
	while (NRF_CLOCK->EVENTS_XOSTARTED == 0) {}
	nrf_gpio_pin_clear(OUTPUT_PIN);
	NRF_CLOCK->EVENTS_XOTUNED = 0;

  return 0;
}