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

[Usha]

I am encountering an MPSL ASSERT: 106, 501 error followed by a HARD FAULT while running my distance measurement example on an nRF52840 using the nRF Connect SDK v2.5.1. The system resets after the fault. Below is the log output:

11:30:10:349 -> E: MPSL ASSERT: 106, 501
11:30:10:351 -> E: ***** HARD FAULT *****
11:30:10:353 -> E: Fault escalation (see below) 11:30:10:356 -> E: ARCH_EXCEPT with reason 3 ...
11:30:17:032 -> E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
11:30:17:032 -> E: Fault during interrupt handling ...
11:30:17:041 -> E: Resetting system

After each reset, the device reboots and starts measuring distances again, but the error repeats after a while.

I am using:

• nRF52832
• nRF Connect SDK v2.5.1
• SoftDevice Controller

Could this be due to a memory issue, a timing problem, or something related to the Bluetooth stack? How can I debug this further?

Any guidance would be appreciated!

[Jakob Ruhe]

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!