About NCS3.1.X MPSL ASSERT

Question

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 · Accepted Answer

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.

Einar Thorsrud · Answer

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.

About NCS3.1.X MPSL ASSERT

Top Replies