RE: Title: MPSL ASSERT and Hard Fault in nRF52832 (nRF Connect SDK v2.5.1)

Edvin — Fri, 14 Feb 2025 07:45:51 GMT

Hello,

The MPSL Assert 106, 501 is caused by an overstay assert. This means that the timeslot provided by the softdevice, in order for the distance measure library to do it's proprietary protocol stuff takes longer than what it is allowed to use. Please see this ticket. Are you running this on an nRF52832 DK, an nRF52840 DK, or custom hardware? Did modifications to the sample? It may be that if it is a bug in the sample, that this is fixed in a later NCS version. Did you try e.g. NCS v2.6.3?

And does the assert occur every time, or just some times? And does it happen randomly, or at the same time every time you run the sample?

Best regards,

Edvin

RE: Title: MPSL ASSERT and Hard Fault in nRF52832 (nRF Connect SDK v2.5.1)

Jakob Ruhe — Wed, 12 Feb 2025 08:55:05 GMT

Hi Usha,

Since neither you or me have access to the source code of the SoftDevice Controller and I do not know anything about your application it is of course very hard to tell! But yes, it could be all the things you mentioned!

Perhaps try to log what your application is doing with the SoftDevice just before the crash.

In general, to catch asserts I usually use a debugger and set a breakpoint at the function `assert_post_action()`. When the assert is triggered I can examine the callstack.

When an assert is triggered by the SoftDevice I am not sure that `assert_post_action()` is called. But you should be able to set a breakpoint in `z_fatal_error()` instead.

With the configuration option `BT_CTLR_ASSERT_HANDLER` it seems like you can configure SoftDevice to use an application handler also.

You can also enable more logging in your application and the Bluetooth stack (CONFIG_BT_LOG_LEVEL).

Now you have a few options. I hope it moves your project forward!