mpsl_init: MPSL ASSERT: 112, 2223 - NCS v2.5.2

Hi,

I am trying to port the DTM example to our board, 52833 based but when DTM is initialised I get about 1400ms of CW then:

00> *** Booting nRF Connect SDK v2.5.2 ***
00> [00:00:00.170,837] <err> mpsl_init: MPSL ASSERT: 112, 2223
00> [00:00:00.170,837] <err> os: ***** HARD FAULT *****
00> [00:00:00.170,867] <err> os: Fault escalation (see below)
00> [00:00:00.170,867] <err> os: ARCH_EXCEPT with reason 3
00>
00> [00:00:00.170,898] <err> os: r0/a1: 0x00000003 r1/a2: 0x00000000 r2/a3: 0x00000000
00> [00:00:00.170,898] <err> os: r3/a4: 0x00000000 r12/ip: 0x200039f0 r14/lr: 0x00033f93
00> [00:00:00.170,928] <err> os: xpsr: 0x41000011
00> [00:00:00.170,928] <err> os: Faulting instruction address (r15/pc): 0x00033fa0
00> [00:00:00.170,959] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
00> [00:00:00.170,989] <err> os: Fault during interrupt handling
00>
00> [00:00:00.171,020] <err> os: Current thread: 0x200039f0 (unknown)
00> [00:00:00.680,297] <err> fatal_error: Resetting system

It's worth noting that the BLE stack is still compiled in, though in this example I'm not calling bt_enable(). That said I'm hoping I might be able to have it start in BLE until a characteristic write happens then stop BLE and switch to DTM.

Anyway hoping someone can shed some light on the ASSERT.

Thanks!

Parents Reply Children
No Data
Related