MPSL ASSERT: 106, 501

[cbooth_lpa]

I am currently working on a project using the nRF Distance Measurement sample in conjunction with Openthread.

However, I am encountering an issue when nodes are positioned more than 10 meters apart. The following assert is triggered:

[00:03:40.057,037] <err> mpsl_init: m_assert_handler: MPSL ASSERT: 106, 501
[00:03:40.163,757] <err> os: hard_fault: ***** HARD FAULT *****
[00:03:40.291,748] <err> os: hard_fault:   Fault escalation (see below)
[00:03:40.397,857] <err> os: hard_fault: ARCH_EXCEPT with reason 3
[00:03:40.504,791] <err> os: esf_dump: r0/a1:  0x00000003  r1/a2:  0x20017d5c  r2/a3:  0x000002c0
[00:03:40.697,296] <err> os: esf_dump: r3/a4:  0x00070d7d r12/ip:  0x00000000 r14/lr:  0x000706e5
[00:03:40.825,286] <err> os: esf_dump:  xpsr:  0x41000018
[00:03:40.932,189] <err> os: esf_dump: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:03:41.059,814] <err> os: esf_dump: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:03:41.167,083] <err> os: esf_dump: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:03:41.317,108] <err> os: esf_dump: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0xffffffff  s[15]:  0xffffffff
[00:03:41.467,102] <err> os: esf_dump: fpscr:  0x00000000

The nodes are nRF52840 DK version 1.0.0 hardware.

I am using nRF Connect SDK version 2.5.2 with the following project configuration:

CONFIG_DEBUG=y
CONFIG_LOG=y
CONFIG_LOG_MODE_DEFERRED=y
CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD=0
CONFIG_I2C=y
CONFIG_GPIO=y
CONFIG_NRFX_PWM0=y
CONFIG_NRFX_PWM1=y
CONFIG_DK_LIBRARY=y
CONFIG_OPENTHREAD_COAP=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_NET_SOCKETS_POLL_MAX=4
CONFIG_OPENTHREAD_NETWORKKEY="XXXX"
CONFIG_OPENTHREAD_PANID=XXXX
CONFIG_OPENTHREAD_XPANID="XXXX"
CONFIG_OPENTHREAD_NETWORK_NAME="XXXX"
CONFIG_OPENTHREAD_JOINER=y
CONFIG_OPENTHREAD_JOINER_AUTOSTART=y
CONFIG_OPENTHREAD_JOINER_PSKD="XXXX"
CONFIG_NET_L2_OPENTHREAD=y
CONFIG_NETWORKING=y
CONFIG_MBEDTLS_SHA1_C=n
CONFIG_FPU=y
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_NAME_CNT=1
CONFIG_BT_SCAN_MANUFACTURER_DATA_CNT=1
CONFIG_BT_SCAN_WITH_IDENTITY=y
CONFIG_BT_ID_MAX=1
CONFIG_BT_EXT_ADV=y
CONFIG_BT_DEVICE_NAME="XXXX"
CONFIG_BT_DDFS=y
CONFIG_DM_MODULE=y
CONFIG_NEWLIB_LIBC=y
CONFIG_MPSL=y
CONFIG_MPSL_TIMESLOT_SESSION_COUNT=1
CONFIG_DM_MODULE_LOG_LEVEL_DBG=n
CONFIG_DM_GPIO_DEBUG=y
CONFIG_DM_HIGH_PRECISION_CALC=y

Could you provide insights into what might be causing this issue?

[Susheel Nuguru]

I need to ask the MPSL team to give the context of when this can happen. I have enough information from you to ask the team. I will write back here once I get the response from the team.

[Susheel Nuguru]

Hi cbooth_lpa,

The assert shows that one of your timeslots sessions have overstayed in the timeslot and did not end it in time. This could happen if you have a high priority context/interrupt_handler that masks the MPSL timer interrupt handling.

The other reason could be that your application is using timeslot API itself in which case the application is responsible to close the timeslot before it expires. In this usecase, it might be that the application does not manage to close the timeslot in time.