Assertion Failure in mpsl_init.c on nRF54L15 – MPSL ASSERT: 1, 1385

Question

Description: 
 We are using nRF54L15 with NCS v3.0.0 , and the following clock configuration: 
 
 CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL =y 
 CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM =y 
 
 Our application only enables Bluetooth and sends advertisement data. This assertion failure does not occur on every power-on, but it happens frequently during startup. We are encountering an assertion failure during initialization of the MPSL module using the nRF54L15. The error message is as follows:

ASSERTION FAIL [ 0 ] @ WEST_TOPDIR /extern/ ncs /nrf/ subsys /mpsl/ init / mpsl_init.c: 307 
 MPSL ASSERT : 1 , 1385 
 
 After enabling the following configuration, the issue appears to be resolved: CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL=y 
 Questions:

What is the root cause of this assertion failure?

Is CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL=y the correct and recommended solution for this issue on nRF54L15?

Are there any side effects or considerations when using external clock control in this context?

We’d appreciate your support on this issue. 
 BR, 
 Angus

Hieu · Answer

Hi Angus, 
 If you haven't, could you please apply the workaround for known issue DRGN-25261, documented at the page linked below? https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/known_issues.html#multiprotocol_service_layer_mpsl 
 What is the root cause of this assertion failure? AngusKu said: Is the root cause of this assertion failure related to the accuracy setting? (Is it likely caused by an incorrect CONFIG_CLOCK_CONTROL_NRF_K32SRC_ACCURACY value, or could there be another reason?) 
 The assert means that the 32MHz crystal didn't start on time. 
 You will need to ensure that CONFIG_MPSL_HFCLK_LATENCY is set correctly, and the load capacitance is correct. 
 Is CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL=y the correct and recommended solution for this issue on nRF54L15? 
 No, it isn't. 
 Are there any side effects or considerations when using external clock control in this context? AngusKu said: What is the functionality of CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL ? What exactly changes when it's set to y compared to n ? 
 It changes the clock driver to Zephyr clock driver instead of the MPSL internal clock driver. However, it is not intended to be used with the nRF54L15.

Hieu · Answer

Hi Angus, 
 AngusKu said: The 32MHz crystal part of the schematic 
 The current board I’m using does not have the CRYSTAL load capacitors populated. AngusKu said: Our EE team has informed us that the missing CRYSTAL load capacitors are causing a ppm deviation in the crystal frequency. We plan to fine-tune this in the next hardware revision to resolve the issue. AngusKu said: If we use the nRF54L15 HFXO configuration with the current hardware setup (i.e. without load capacitors), Could this cause any issues or unexpected behavior ? AngusKu said: Could you advise how to reconfigure the HFXO settings accordingly ? 
 The nRF54L15 support an adjustable internal capacitor, so not using the external capacitor is fine. Refer here: OSCILLATORS — Oscillator control . 
 The internal capacitor simply has to be configured correctly. We get to this next. 
 AngusKu said: What you have set in the hfxo DeviceTree node. We use the same configuration for the nRF54L15 DK 
 Referring to the configuration: 
 &hfxo {
 load-capacitors = "internal";
 load-capacitance-femtofarad = <15000>;
}; 
 In configures the device to set the internal capacitance to 15000fF (femtofarad). 
 This is not the correct value for your crystal. Referring to the same documentation linked above, if we assume the parasitic capacitance from the PCB is the same on both ends of the crystal, the internal capacitance value can be calculated with: 
 C_int = C_crystal_load * 2 - C_pcb. 
 You can refer to your hardware engineer for a precise estimation of the PCB parasitic capacitance. From our experience, it is usually under 1pF, so you can use 0.5~1pF if needed. 
 You can find the load capacitance for your crystal is specified at 4pF. 
 Please adjust the load-capacitance-femtofarad property according to the calculation, and retry with CONFIG_MPSL_HFCLK_LATENCY value of 1366 (default + DRGN-25261 workaround). 
 AngusKu said: Once the load capacitors are added in the next revision — including the associated ppm adjustment (e.g., related to BT_MESH_TIME_SRV_CLOCK_ACCURACY ) 
 So, please note that the BT_MESH_TIME_SRV_CLOCK_ACCURACY is based off of the LFCLK, 32kHz, not the HFCLK we are talking about. Therefore, changes in the HFCLK accuracy shouldn't impact the LFCLK accuracy and related parameters. 
 This is unless you are configuring the LFCLK to source from the HFCLK. 
 AngusKu said: Would adjusting CONFIG_MPSL_HFCLK_LATENCY affect communication ? 
 
 specifically when connecting to the Amazon gateway over BLE to exchange data? 
 Let's try adjusting the Devicetree config first and see how it works.

Assertion Failure in mpsl_init.c on nRF54L15 – MPSL ASSERT: 1, 1385

Top Replies