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

[BillB]

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!

[BillB]

Hi Vidar,

>  I also tried irq_disable(RADIO_IRQn) after both dtm_init() and dtm_test_transmit() but that made no difference either.

Actually I made a mistake and put the 2nd irq_disable in the wrong place.

This DOES work, and if I do this at the top of main() with a k_sleep() after it I get a solid CW and then it'll even continue on to starting BLE, which works for me since I can then use DFU to put the real firmware back after we're done.

So maybe that'd be enough, but still it'd be better for me if I could use the BLE trigger since I'd like to use the char write to pick the frequency. That still doesn't work - I still get the same MPSL ASSERT. Note that in this case the char write handler is setting a flag that causes the main thread to do:

bt_disable();
irq_disable(RADIO_IRQn);
k_sleep(K_MSEC(500));
NVIC_ClearPendingIRQ(RADIO_IRQn);
dtm_init(&dtm_iq_report_callback);
irq_disable(RADIO_IRQn);

Any ideas? I thought maybe there's an interrupt pending so that the crash is happening as soon dtm_init() enables the interrupt, but haven't got much evidence to back that up. 

Thanks!

[Vidar Berg]

Hi,

Glad to hear you've made progress on this. We currently do not have any samples demonstrating how to combine DTM and BLE in a single firmware image.

BillB said:

So maybe that'd be enough, but still it'd be better for me if I could use the BLE trigger since I'd like to use the char write to pick the frequency. That still doesn't work - I still get the same MPSL ASSERT. Note that in this case the char write handler is setting a flag that causes the main thread to do:

Please check if the return value from bt_disable() is zero and not a negative error code. As an alternative (a 'hack'), you could use one of the retention registers (GPREGRET – 1 byte each) to store the DTM configuration or mode you want to use, and then call sys_reboot() (equivalent to NVIC_SystemReset) so you can enter DTM on subsuequent boot before enabling the BLE stack.