Radio Test and BT exlusive coexistense in same firmware image

[Taavi Jantson]

Hi,

First I like to share some background. We have a normal BLE application, which is made in nRF Connect and for nRF52833. We like to have radio test functionality and BLE functionality in the same firmware image. It doesn't mean that BLE functionality and radio test functions are used at the same time. Radio test commands are commanded over UART and BLE is not even initialized (bt_enable()) in that case. Seems reasonable to expect that if the BLE is not even enabled, then it should be possible to use radio test functionality.

Now about the problem. My experiments show that when BLE functionality is enabled from the configuration (CONFIG_BT=y) then the modulated carrier TX test crashes the system. It seems to me that BLE enabling from the configuration already takes some resources statically and that even without bt_enable() call.

Is there any thinkable way how BLE feature enabled from the configuration can coexist with radio tests in the same firmware image? Important here is that BLE is even not dynamically initialized when radio tests are used.

By the way, I have made the experiment with the Nordic provided radio test example, where I have only enabled the BLE from configuration (CONFIG_BT=y) and I have observed the same system hard fault.

The hard fault itself looked like the following:

E: MPSL ASSERT: 112, 2189
E: ***** HARD FAULT *****
E: Fault escalation (see below)
E: ARCH_EXCEPT with reason 3

E: r0/a1: 0x00000003 r1/a2: 0x0000000a r2/a3: 0x00000000
E: r3/a4: 0x2000ccbe r12/ip: 0x00000000 r14/lr: 0x0003f407
E: xpsr: 0x61000011
E: Faulting instruction address (r15/pc): 0x0003f412
E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x20002aa0 (main)
E: Resetting system

[Susheel Nuguru]

I was assuming that nothing is owned by the softdevice controller before ble is enabled, but I am not 100% sure about this.

Can you attach your project here so that I can test what causes this hardfault?

[Taavi Jantson]

You can very easily reproduce the issue by taking the radio test example 'nrf\samples\peripheral\radio_test', adding CONFIG_BT=y to the configuration and executing the command 'start_tx_modulated_carrier' from the command line.

The first problem you will notice is that the function static uint8_t rnd8(void) will never return as the event doesn't get active. This random number generation can be replaced by something else and is not important right now. So to continue I just replaced this with the standard lib rand() function.

Next, you should observe the not intended system reset after the function nrf_radio_task_trigger(NRF_RADIO, NRF_RADIO_TASK_TXEN) gets called.

For some reason, the radio test example gives just plain system reset and in my product application I get MPSL ASSERT, but still, both are bad.

0333.radio_test.zip

[Susheel Nuguru]

Taavi, 

I can reproduce the restart when enabling CONFIG_BT=y. At this point it does not look like this is due to writing to RADIO registers. Most likely a stack corruption. I haven't figured that out yet. But I am asking the softdevice controller team as to when the controller takes ownership of the peripherals exactly. Will be back to you when I have more info.

[Susheel Nuguru]

The peripherals seems to be owned at mpsl_init which is at the system startup. CONFIG_BT=y seems to translate to mpsl owership of these restricted peripherals.

Please add below in your proj.conf

DYNAMIC_DIRECT_INTERRUPTS=y
MPSL_DYNAMIC_INTERRUPTS=y

and uninitalize mpsl in your radio test initialization after the clock is configured as below

	err = mpsl_lib_uninit();
	if (err) {
		printk("Unable to uninit MPSL\n");
		return;
	}

This will remove the controller's ownership of those peripherals.

[Taavi Jantson]

Thank you.

That is exactly what was needed.

I have verified that no more crashes for the radio test example.

Note for future users! Quite the latest nRF SDK is required to use this solution.