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

[DhruvitDV2707]

Hi team,

I am experiencing a persistent MPSL assertion 1519 on nRF54L15 that occurs consistently at ~5 seconds after BLE advertising starts. The assertion indicates that the 32MHz HFXO (High-Frequency Crystal Oscillator) didn't start on time for radio transmission. All recommended software-based fixes have been attempted without success.

Error Message:
"""

ASSERTION FAIL [0] @ WEST_TOPDIR/nrf/subsys/mpsl/init/mpsl_init.c:307
MPSL ASSERT: 1, 1519

[00:00:05.382,477] <err> os: ***** HARD FAULT *****
[00:00:05.388,037] <err> os: Fault escalation (see below)
[00:00:05.394,292] <err> os: ARCH_EXCEPT with reason 4

[00:00:05.400,206] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000133 r2/a3: 0x00000000
[00:00:05.408,893] <err> os: r3/a4: 0x00000004 r12/ip: 0x00000040 r14/lr: 0x0002aa7f
[00:00:05.417,571] <err> os: xpsr: 0x010000f5
[00:00:05.422,788] <err> os: Faulting instruction address (r15/pc): 0x0003723c
[00:00:05.430,695] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:05.438,420] <err> os: Fault during interrupt handling

[00:00:05.444,850] <err> os: Current thread: 0x20003d90 (idle)
[00:00:05.451,361] <err> os: Halting syste
"""

Hardware Details:
"""
- Chip: nRF54L15
- Development Kit: nRF54L15 DK (Part Number: 453-00001-K1, Product Code: BL54L15)
- Board Target: nrf54l15dk/nrf54l15/cpuapp
"""

Software Details:
"""
- nRF Connect SDK Version: v3.1.1 (commit: e2a97fe2578a)
- Zephyr OS Version: v4.1.99 (commit: ff8f0c579eeb)
- Build System: West build with pristine builds
- Application: Simple BLE peripheral with advertising and Nordic UART Service
"""

Proj.conf configuration(Key Settings):

# Clock Configuration - Internal RC Oscillator (tried as workaround)
CONFIG_CLOCK_CONTROL_NRF=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_PERIOD=4000
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

# MPSL HFCLK Latency (increased significantly)
CONFIG_MPSL_HFCLK_LATENCY=8000

# Power Management (disabled to prevent GRTC sleep issues)
CONFIG_PM=n
CONFIG_PM_DEVICE=n

# Stack Sizes (increased to prevent stack overflow)
CONFIG_MAIN_STACK_SIZE=3072
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=3072
CONFIG_MPSL_WORK_STACK_SIZE=1024
CONFIG_IDLE_STACK_SIZE=256
CONFIG_ISR_STACK_SIZE=2048
CONFIG_BT_RX_STACK_SIZE=2048
CONFIG_BT_HCI_TX_STACK_SIZE=1536
CONFIG_BT_NUS_THREAD_STACK_SIZE=1536

# BLE Configuration
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_MAX_CONN=2
CONFIG_BT_DEVICE_NAME="TestDevice"

##QUESTIONS:

1. Could this be a hardware issue with the DK's crystal, or is it purely software?
2. Are there any DK-specific configuration requirements for nRF54L15 that differ from other nRF54 series?

Thank you for your assistance!

[Einar Thorsrud]

Hi,

Could this be a hardware issue with the DK's crystal, or is it purely software?

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.

Are there any DK-specific configuration requirements for nRF54L15 that differ from other nRF54 series?

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.

1. My understanding is that you are testing on the DK?
2. Have you made any changes to the DK hardware?
3. Have you made any changes to the SDK itself? (You can check for any changes using "west status")
4. 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;
}

[DhruvitDV2707]

Hi,

Thank you for your quick reply.

Einar Thorsrud said:

My understanding is that you are testing on the DK?

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

Einar Thorsrud said:

Have you made any changes to the DK hardware?

-> None. It's as it is.

Einar Thorsrud said:

Have you made any changes to the SDK itself? (You can check for any changes using "west status")

-> 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.

Einar Thorsrud said:

If you test with an unmodified example application (for instance Peripheral LBS). Does the assert happen then as well?

-> 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
"""

Einar Thorsrud said:

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?

-> 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?

[Einar Thorsrud]

Hi,

DhruvitDV2707 said:

-> 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. 

"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)?

DhruvitDV2707 said:

-> 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.

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.

DhruvitDV2707 said:

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

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

[DhruvitDV2707]

sdk_diff.txt

Hi,

Einar Thorsrud said:

Can you share the output from west status or alternatively revert everythign (or check out a new SDK if that is easier)?

-> I have attached a file for your reference.

Einar Thorsrud said:

Or did you have something else in mind?

-> 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?

[Einar Thorsrud]

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.)

[DhruvitDV2707]

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.

[DhruvitDV2707]

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.