RE: MPSL ASSERT: 112, 695 (NCS 3.1.1)

tobias-t — Wed, 11 Feb 2026 08:53:55 GMT

Thank you for your prompt answer!

We figured out what the issue was: we accidentally had the RTC0, which we otherwise don't use, enabled in the devicetree, where the Zephyr driver then (also) configures it. Simply removing it fixed the issue.

Unfortunately does mpsl_init.c currently (v3.1.1) not validate this in its Kconfig validation part

RE: MPSL ASSERT: 112, 695 (NCS 3.1.1)

Samruddhi Jadhav — Mon, 09 Feb 2026 10:12:57 GMT

Hi,

According to some similar cases, the causes of the MPSL assert errors after upgrading can be due to:

32 MHz crystal (HFCLK) issues such as the crystal starting too slow or if it's is marginal due to solder joints, incorrect load capacitors or if these aren't there, temperature/supply effects. I would also suggest you to check that your app isn't using TIMERO after upgrading. Also ensure that you don't allocate PPI/DPPI channels or other resources which MPSL reserves. You can also test and increase CONFIG_MPSL_HFCLK_LATENCY and check if the asserts still show. Another cause can also be long time periods with interrupts disabled or heavy flash/ rram operations while BLE and other radio activity runs. Unfortunately, because the MPSL assert pair you mentioned is an internal code, we cannot decode those numbers.

Best Regards,

Samruddhi