MPSL Assert File 112, line 1588

[joar@nofence]

Hello,

We are seeing a few strange cases of devices reporting MPSL assertion on file 112, line 1588. The assertion comes from the softdevice, so its a bit tricky to understand if the issue is due to wrong configuration or just broken HW. The assertion is quite rare (around 0.01% of relevant devices are reported this at some point during the day), but not rare enough to be ignored. We are not able to reproduce this in-house, but we would like to undertand what is causing it if possible.

So what does this specific assert mean?

Also, is the various assertions documented anywhere?

- nRF Connect SDK v3.0.1

- Zephyr v4.0.99

[Einar Thorsrud]

Hi,

Which nRF device are you using?

The assert indicate that the HFXO was not not ready on time. Most likely, you need to adjust CONFIG_MPSL_HFCLK_LATENCY. The default value for that in SDK 3.0 was too low for some crystals on nRF54 series devices. To optimize the value you can measure the startup time and configure twice the measured value (to account for variation). Alternatively, you can set a higher value such as 1650. The downside of a higher value is that it causes the crystal oscillator to start earlier, increasing the average power consumption a bit.

It is also worth verifying that the crystal you are using is within the specifications of the nRF and that you have configured proper load capacitors, though if this was far off you should see other problems as well.

[joar@nofence]

Great, thanks for the quick reply! We will have a check.
the issue in question appears on some nRF52840. Sounds like this could possibly be a symptom of damaged hw as well then.


update: Looks like we have more than enough latency in our config, so then I guess a HW fault is the reason. If anything, we should probably lower it.

10 iterations, HFCLK startup min=244 max=274 avg=264 us

our current CONFIG_MPSL_HFCLK_LATENCY = 1400 us

void hfclk_startup_measure(void)
{
	uint32_t min_us = UINT32_MAX;
	uint32_t max_us = 0;
	uint64_t sum_us = 0;
	int valid_count = 0;

	NCLOG_INF(NCID, TRice( iD( 3613),"inf: HFCLK startup measurement: %d iterations \n", CONFIG_HFCLK_STARTUP_MEASURE_COUNT));

	for (int i = 0; i < CONFIG_HFCLK_STARTUP_MEASURE_COUNT; i++) {
		/* Stop HFCLK and wait for it to settle */
		nrf_clock_task_trigger(NRF_CLOCK, NRF_CLOCK_TASK_HFCLKSTOP);
		k_busy_wait(200);

		/* Clear the done event */
	nrf_clock_event_clear(NRF_CLOCK, HFCLK_DONE_EVENT);

		/* Start timing */
		uint32_t start = k_cycle_get_32();
		nrf_clock_task_trigger(NRF_CLOCK, NRF_CLOCK_TASK_HFCLKSTART);

		/* Spin-wait for HFCLK to be ready */
		while (!nrf_clock_event_check(NRF_CLOCK, HFCLK_DONE_EVENT)) {
			/* spin */
		}

		uint32_t end = k_cycle_get_32();
		uint32_t duration_us = (uint32_t)(((uint64_t)(end - start) * 1000000ULL) /
						  sys_clock_hw_cycles_per_sec());

		NCLOG_INF(NCID, TRice( iD( 5731),"inf: HFCLK iter %d: %u us \n", i, duration_us));

		/* Discard first measurement (cold crystal startup) */
		if (i == 0) {
			continue;
		}

		valid_count++;
		sum_us += duration_us;
		if (duration_us < min_us) {
			min_us = duration_us;
		}
		if (duration_us > max_us) {
			max_us = duration_us;
		}
	}

	if (valid_count > 0) {
		uint32_t avg_us = (uint32_t)(sum_us / valid_count);
		uint32_t suggested_latency = 2 * max_us;

		NCLOG_INF(NCID, TRice( iD( 2672),"inf: HFCLK startup min=%u max=%u avg=%u us \n", min_us, max_us, avg_us));
		NCLOG_INF(NCID, TRice( iD( 6729),"inf: Suggested MPSL_HFCLK_LATENCY = %u us \n", suggested_latency));
	}
}

[Einar Thorsrud]

Hi,

Yes, there should be no problem here then. I would suggest getting back one of the failing devices and XTAL check the startup time on that specifically. Also, it is worth double checking the HW surrounding the xtal. 

Regarding shortening the HF clock latency I would not necessarily recommend doing that unless you have a good reason to do so (the only benefit would be a slight power optimization). In earlier SDK versions this was always set to 1400 and was non-configurable.