MPSL ASSERT: 112, 695 (NCS 3.1.1)

[tobias-t]

Hi,

After upgrading from NCS 2.5.2 to NCS 3.1.1, I get quite frequent MPSL assertion errors on a nRF52840.


Can you shed some light into what this assertion error is about, please?

Thanks

[Samruddhi Jadhav]

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

[tobias-t]

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