About NCS3.1.X MPSL ASSERT

[bevis]

   Platform : NRF54L15
 NCS(2025.9): 3.0.2
NCS(2025.10): 3.1.1  Commit: e2a97fe2578a
      Zephyr: 4.1.99 Commit: ff8f0c579eeb

Cause of the issue
         Earlier, when I were producing products (around 600 units with 2025.9), about 30% of the chips had difficulty connecting. Later, it was found that the boards that disconnected immediately after connecting were stuck at "MPSL ASSERT: 109, 585."
         At that time, the SDK used was 3.0.2. After consulting AI, He was advised to increase CONFIG_MPSL_HFCLK_LATENCY to 1400-1650. The original SDK default was 845, and after I increased it to 1000, the connection yield of the product improved. However, the actual use was still not very stable.
         Until the 3.1.0 update in October 2025, which mentioned optimizations related to MPSL, I updated the SDK to 3.1.1. The actual use was indeed much more stable than 3.0.2, but "MPSL ASSERT: 109, 585" still occasionally occurred.

---

I think the assertion scenario may be due to the following two possibilities:
1. My system has long delay blocking, which may currently be reflected in the regular operation of RRAM in my system, such as writing logs to RRAM once per second, or writing to external norFlash.
      I have also evaluated the interface delay for writing to RRAM. The schemes are NVS > ZMS > RRAM single. Since using the system storage management scheme may cause uncontrollable and mysterious delays, I ended up directly operating on RRAM single.
2. The SDK 3.1.1 has not completely fixed the MPSL temperature drift issue.

[Einar Thorsrud]

Hi,

Do you have a bootloader in the device? If so, can you double check that the LF clock source you have configured is the same in the bootloader and application? We have seen this assert before when the bootloader used LFXO and application used LFRC.

[bevis]

Yes, I have mcuboot, and all set the HFXO

&hfxo {
	load-capacitors = "internal";
	load-capacitance-femtofarad = <16250>;
};

[bevis]

and I found they all set 

CONFIG_DT_HAS_NORDIC_NRF54L_HFXO_ENABLED=y
CONFIG_DT_HAS_NORDIC_NRF54L_LFXO_ENABLED=y

[Einar Thorsrud]

I see  this looks good. Can you le me know which 32.768 kHz and 32 MHz crystals you have? (exact part numbers so that I can see the datasheet)?

[bevis]

EPSON-FC1610AN_Brief.pdfFA1210AN_X1E0004110008_en.pdf

[Einar Thorsrud]

Hi,

Thank you. Did you try a higher value for CONFIG_MPSL_HFCLK_LATENCY? It could be good to set this to 1650 and also update or the config for your board files if you set it there, similarly to what was done in the for he DK in this commit.

It could also be useful to test the startup time of the 32 MHz crystal oscillator (HFXO). That can be done using this code snippet (put into for instance the hello_world sample project, and adjust the OUTPUT_PIN definition to a pin you can access on your hardware):

#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;
}

Measure the last pulse, and the duration of that is the time from starting the HFXO until it is calibrated and ready for use with the radio. Then multiply this by two, and use that value with CONFIG_MPSL_HFCLK_LATENCY.

[bevis]

Increasing CONFIG_MPSL_HFCLK_LATENCY to 1650 is a very bad decision. I strongly urge the SDK not to do so. This will significantly increase the system's static power consumption, including the power consumption of the RF oscillator. Increasing this value will negate the efficiency of the high - end manufacturing process of NRF54.

Regarding the code you provided, are you suggesting that I measure the 32M crystal oscillator at startup and dynamically set CONFIG_MPSL_HFCLK_LATENCY based on the obtained value?

[Einar Thorsrud]

Hi,

It is only the default value that is increased as we have seen problems on several custom boards with higher value, and quite a few user use the DK board files without adapting properly to their needs. You are free to optimize the value to match your hardware. (The value 1650 is also what was used previously for many years for older devices when this was not configurable.)

Yes. the latency should ideally be set based on the actual crystal you are using. This way, you can find a sweet spot that allows lower power consumption by not starting the crystal too early, while at the same time making sure it is started early enough for your specific crystal that you do not run into problems. Note the recommendation of multiplying the measured value by two (as explained in the API doc), as there are variations from crystal to crystal, and other factors like the temperature also affect startup time.

EDIT: I read your post again now. I am not suggesting you do this dynamically. I suggest you test the startup time on your bench in room temperature on a typical device. Then use this as a basis for the static configuration.