• State Not Answered
  • Replies 37 replies
  • Subscribers 75 subscribers
  • Views 3295 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 316987
Options

MPSL not working correctly with custom ble hci_rpmsg image

duralabs

We have been trying to get MPSL up and running in a BLE and ESB coexistence project but haven't had much luck.

We use an app core image that enables the BLE interface and listens for RPC events from the net core. The net core is a modified version of the BLE hci_rpmsg image with support added for RPC and ESB. We use RPC to notify the app core when data is received over ESB from other Nordic devices. BLE only needs to run for a short period of time and that period of time is user initiated. When implementing the MPSL piece, the BLE hci image is able to bind to "zephyr_bt_hci_rpmsg_ipc" but the "net_buf_get" while loop that delivers data to the app core is blocked from sending anything. We haven't been able to figure out how to allow "net_buf_get" to send BLE data to the app core once MPSL is implemented. 

When we init MPSL, we schedule a request to open a session and create a time slot. This process completes without any issues and we are notified that the time slot has begun. At this time, we'll enable ESB and send some data to a nearby nrf5340dk and that process is also successful. After this happens, we would assume that we would notify MPSL that the process has completed and that the bluetooth communication channel should be allowed to continue. 

We have reviewed the following MPSL sample projects but continue to run into errors with the bluetooth hci communication piece.

  1. https://github.com/too1/ncs-esb-ble-mpsl-demo/tree/master
  2. https://github.com/nrfconnect/sdk-nrf/tree/main/samples/mpsl/timeslot

Oddly enough, the bluetooth portion worked without any issues until we enabled the following kconfig values for MPSL.

CONFIG_MPSL=y
CONFIG_MPSL_TIMESLOT_SESSION_COUNT=2
CONFIG_RING_BUFFER=y
CONFIG_DYNAMIC_INTERRUPTS=y
CONFIG_DYNAMIC_DIRECT_INTERRUPTS=y

Are there any examples where MPSL is used for BLE and ESB coexistence on a board with an app core and a net core? Unfortunately the first link above looks like it runs on an older infrastructure that doesn't apply to our use-case. Any help would be appreciated as we've spent a lot of time trying to get MPSL working correctly.

  • 0

    Hi Mike

    The only sample showing how to run ESB and BLE in timeslot on the nRF53 is this one.

    I have an ambition to update the ncs-esb-ble-mpsl-demo sample to run on the nRF53 as well, but I don't know how much time I will need to get this implemented. When I start work on this I will use the other sample for reference, no need to reinvent the wheel. 

    Best regards
    Torbjørn 

  • 0 in reply to ovrebekk

    Thanks for the response.

    We tried building the project that you suggested but there are quite a few build errors. For the app core, the build complains about unknown type name 'NRF_RADIO_Type'. For the net core, the build complains about undefined reference to `mpsl_work_q'. 

    For the NRF_RADIO_Type error, I see that nrf5340_network.h contains that definition but I'm unsure why the application core is trying to reference it.

    Do you have any recommendations for getting the project to build correctly?

  • 0 in reply to duralabs

    Hi Mike

    Which version of the SDK are you using to build it? 

    The example is quite old, and I believe it was designed for v2.0.2 or v2.1.0 of the nRF Connect SDK. 

    Also, it is odd that the app core build complains about the NRF_RADIO_Type. You made sure to build the cpuapp project for the app core and the cpunet project for the net core? 

    I will set aside some time tomorrow to try and build it myself, and see if I get the same error. Starting next week I will try to modify my own example to do something similar in order to be able to use it on the nRF53, while also updating it for the latest version of the SDK. 

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    We're using SDK version 2.4.1.

    Yeah I thought it was pretty strange too. The app project, built for the app core, still tries to access net core defines. It looks like the ESB import at the app level is causing those errors.

  • 0 in reply to duralabs

    Hi Mike

    v2.4.1 is surely going to fail, this version is much more recent than the sample. 

    I have now tried to build in v1.9.1, v2.0.2 and v2.1.4 without much success, and I am out of time for the day...

    I might have to wait until next week before looking into this further, then I am planning to spend some time on merging this example with my own, and make sure it runs in later NCS versions. 

    Best regards
    Torbjørn

Related
Terms of service