Multiprotocol Service Layer (MPSL) - BLE coexistence with proprietary communication stack

Question

Background

In our company, we have developed a prioprietary synchronized communication stack that we would like to run on nRF52 devices simultaneously with BLE. To date, our solution works without BLE flawlessly on nRF52832 and nRF52833 devices using the nRF SDK (using low-level HAL functions).

We would like to go a little further and have our communication stack running simultaneously with BLE using the Zephyr ecosystem. I have done some research and as far as I know, MPSL should be used for this purpose. My main and only source of information is the documentation published on your website: developer.nordicsemi.com/.../README.html

I did some experiments with MPSL. I ran the LBS example with Zephyr and added some code to test the MPSL API. Everything seems to work as intended.

Questions

(1) A convenient handler for handling radio procedures initialized by mpsl_radio_notification_cfg_set is provided. What is the right solution to distinguish which component is using the radio?
If BLE is active, its activity is handled within the same radio notification. At this time, I request a timeslot, resulting in mixed radio activity from BLE and my application. Given that the application's time allocation can be delayed, blocked or canceled, any external solution seems difficult to implement.

(2) How do I integrate my own wireless PHY with BLE? Can I reconfigure all radio registers and use RADIO_IRQ interrupt in the active MPSL slot?
nrfx has no KConfig option to enable the radio controller. It appears that there is no low-level driver available. However, the nrf_radio.h header with low-level functions is available and is quite similar to the radio functions from the previous nRF SDK.

matkub · Accepted Answer

Sorry for my week-long absence. 
 I made it work properly (at least within a simple proof-of-concept test). I used the EGU and PPI in such a way that RATIO_IRQn is no longer involved. The radio events, which are necessary for the proper operation of our radio controller, were connected via PPI to the EGU to trigger the SWI1_EGU1_IRQn software interrupt. All the KConfig entries enabling dynamic interrupts seem to be unnecessary. My interrupt, EGU and PPI are initialized once and at the initialization stage, and then only the corresponding PPI channels are turned on at the beginning of the time interval and turned off before the end. 
 
 Einar Thorsrud thank you for the link to the ncs-esb-ble-mpsl-demo. As I noticed the only difference against my earliest trials was the absence of CONFIG_MPSL_DYNAMIC_INTERRUPTS=y in the example you gave me. However, since the above solution works, I would like to end this issue here. But if the solution with PPI and EGU will fail for some other reason I will rework it once again - for sure.

Einar Thorsrud · Answer

Hi, 
 I am not sure exactly what the problem is at this point, but perhaps it is worth looking at the unoficcial ncs-esb-ble-mpsl-demo that a coleague of me made? This demonstrated ESB in MPSL timeslots and BLE. You should also take a look at the project configuration file there, particularily: 
 CONFIG_DYNAMIC_INTERRUPTS=y
CONFIG_DYNAMIC_DIRECT_INTERRUPTS=y

CONFIG_ESB=y
CONFIG_ESB_DYNAMIC_INTERRUPTS=y

Multiprotocol Service Layer (MPSL) - BLE coexistence with proprietary communication stack

Top Replies