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

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!

Parents
  • 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

Reply
  • 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

Children
No Data
Related