Regarding the MPSL ASSERT: 1, 1519 issue

[sean]

Hi，

    During full-device testing, we observed that two devices encounter the MPSL ASSERT: 1, 1519 error after approximately one hour of operation, which causes the MCU to reboot. In addition, several other devices experience the same error about once per day, while the majority of devices operate normally.

    We have confirmed that this is related to an HF crystal oscillator startup timeout. We would like to confirm the timeout duration and the number of retry attempts for the crystal startup.

The main MCU is nRF54L15, using SDK v3.1.0.
CONFIG_MPSL_HFCLK_LATENCY = 1800

[Susheel Nuguru]

How many devices did you test? I mean I wanted to know the failing rate of the devices. You said two devices see this issue, out of how many? 

We might have to do a failure analysis on the failing device if it is only happening on the 2 devices.

[Ron Liu]

Currently, 3-4 devices have been found to be abnormal, with a probability of about 1 in 20.

[Susheel Nuguru]

Hmm, that seems high. Are you sure that your firmware is not disabling global interrupts at any part or time in your code? The assert says that the app somehow kept the CPU for itself a bit longer than it should. Are you using timeslot API? if yes, did you receive MPSL_TIMESLOT_SIGNAL_OVERSTAYED event before the assert?  

[Ron Liu]

After extensive cross-testing, we have concluded that this is not a software logic issue but rather related to the crystal oscillator startup time. The specific problem we need to confirm is as follows:

Currently, we have set CONFIG_MPSL_HFCLK_LATENCY to 1800 µs, while the actual measured crystal oscillator startup time is around 1000 µs. In theory, this configuration should not trigger an assertion; however, in practice, the assertion still occurs.

We therefore suspect that the timeout used to trigger the assertion is effectively 1000 µs instead of the configured CONFIG_MPSL_HFCLK_LATENCY value. We would like the Nordic team to review the MPSL source code to confirm this behavior.

[Susheel Nuguru]

Ron Liu said:

We therefore suspect that the timeout used to trigger the assertion is effectively 1000 µs instead of the configured CONFIG_MPSL_HFCLK_LATENCY value. We would like the Nordic team to review the MPSL source code to confirm this behavior.

I have checked the MPSL code myself and that should not be the case. 

One suspect could be that in nrf/subsys/mpsl/init/mpsl_init.c you have this code

#if !defined(CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL)
#if defined(CONFIG_CLOCK_CONTROL_NRF) && DT_NODE_EXISTS(DT_NODELABEL(hfxo))
	mpsl_clock_hfclk_latency_set(z_nrf_clock_bt_ctlr_hf_get_startup_time_us());
#else
	mpsl_clock_hfclk_latency_set(CONFIG_MPSL_HFCLK_LATENCY);
#endif /* CONFIG_CLOCK_CONTROL_NRF && DT_NODE_EXISTS(DT_NODELABEL(hfxo)) */
#endif /* !CONFIG_MPSL_USE_EXTERNAL_CLOCK_CONTROL */

...

If you have a device tree node for hfxo and a startup_time_us, then it seems that it will take that instead of CONFIG_MPSL_HFCLK_LATENCY. Check your finally built zephyr.dts and check if you have some entry there witih hfxo and startup_time_us. I am guessing, most likely you do have some entry there with value less than 1800us.