To run Thread, must the MPSL library be used? MPSL hard fault on breakpoint

[BenFT]

The Thread examples all include MPSL. We are running the same but don't need BLE at the moment. Can the MPSL be removed?

A reason for asking this is currently we get a hard fault in the MPSL library when ever a breakpoint is hit, so it stops us debugging the application.
It is possible to debug with MPSL? We are just trying to use the CLI at the moment to test Thread / TCP so we are not adding code in this area yet. There are other tasks running doing uart actions / adc etc.

[00:01:51.737,823] <err> mpsl_init: MPSL ASSERT: 112, 2749
[00:01:51.737,854] <err> os: ***** HARD FAULT *****
[00:01:51.737,884] <err> os: Fault escalation (see below)
[00:01:51.737,884] <err> os: ARCH_EXCEPT with reason 3

[00:01:51.737,915] <err> os: r0/a1: 0x00000003 r1/a2: 0x20007128 r2/a3: 0x20007128
[00:01:51.737,945] <err> os: r3/a4: 0x00089711 r12/ip: 0x2001e658 r14/lr: 0x0004339d
[00:01:51.737,945] <err> os: xpsr: 0x4100001b
[00:01:51.737,976] <err> os: s[ 0]: 0x00000000 s[ 1]: 0x00000000 s[ 2]: 0x00000000 s[ 3]: 0x00000000
[00:01:51.738,006] <err> os: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000
[00:01:51.738,037] <err> os: s[ 8]: 0x00000000 s[ 9]: 0x00000000 s[10]: 0x00000002 s[11]: 0x00000000
[00:01:51.738,067] <err> os: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000
[00:01:51.738,098] <err> os: fpscr: 0x00001900
[00:01:51.738,128] <err> os: Faulting instruction address (r15/pc): 0x0002f71c
[00:01:51.738,159] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:01:51.738,189] <err> os: Fault during interrupt handling

[00:01:51.738,220] <err> os: Current thread: 0x20007128 (idle)
[00:02:11.490,173] <err> os: Halting system

[Einar Thorsrud]

Hi,

Yes, the stack depends on MPSL, so you cannot skip it. The MPSL assert 112, 2749 indicate that you continued from a breakpoint or was stepping in the code, and then there will be timing issues leading to an assert.

To work around this you can move a breakpoint and reset to run further, instead of stepping or continuing from a breakpoint.

[BenFT]

OK, thanks for confirming.
I've experienced this with the BLE soft device, in this case is it the Thread functions or the MPSL in particular which stops stepping or continuing from a break-point?

[BenFT]

And as info for others who tread this way:

I had the config for auto Thread start:

CONFIG_OPENTHREAD_MANUAL_START=n

which runs before main(), so the usual breakpoint at the start of main() means you hit the assert immediately on starting the application in the debugger.