Is there a way of running BLE on the network core only on nRF5340?

RE: Is there a way of running BLE on the network core only on nRF5340?

nfbe — Tue, 11 Mar 2025 18:21:42 GMT

Thanks a lot for your comments and very prompt replies, Kenneth!

I will take a deep look into this Thread Viewer option - I believe that will help me to understand what is happening much more deeply.

... and, of course, tutorials will be helpful in many cases...

I will take a look into the remote procedure calls, too... somehow I have the feeling, there will be a rather simple solution to my very specific problem using the nrf5340... I just have to put in a little more time to think about it...

...and I will definitely look into the nrf54 series as you suggest - even though I am hesitatant to change the core of my device between project phases - I would absolutely prefer to stick to what I have and only make minor fixes and improvements, hoping that the next HW-design might be ready to be my product.

Thanks for your advice - you helped me a lot to make up my mind and for now, I have good ideas how to continue. I will come back with more specific questions - if I need to.

I think, we can close this for now.

Regards,

Jens

RE: Is there a way of running BLE on the network core only on nRF5340?

Kenneth — Mon, 10 Mar 2025 21:04:56 GMT

Hello,

You are free to solve this with whatever approach you are most comfortable with, I know everyone have their own preferences. Here is in any case my input.

We have a few tutorials in general for the nRF Connect SDK:
https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/
https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/
https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/

In your case I would in specific check out the "Thread Viewer" further down on this page:
https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-2-debugging/topic/debugging-in-vs-code/

Then you can see the priority of all the threads running in the appcore, and configure the thread you want to run to be either higher or between the existing threads running.

Unfortunately the priorities with negative value are cooperative threads, which once started can't be preempted, not even by higher priority threads. That said, those cooperative threads should be short by design, I would not expect them to block more than potentially a few hundred of us in worst case.

It's an option to have the algorithms run in a thread with high priority, and then each time you want to send data you transfer that to a work queue to handle the bt_gatt_notify().

The only thing I can think of that may block in the tens of ms is if you are doing flash operations, such as storing data to flash, which may indirectly trigger erasing flash pages, moving around data in flash etc, this will take a long time, but this should only occur for instance shortly after bonding, or if you are supporting multiple bonds, it may also occur if you have enabled BT_KEYS_OVERWRITE_OLDEST shortly after connection is established.

All that said, an alternative is to look into this example:
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bluetooth/rpc_host/README.html

The problem with the RPC example is that it's experimental, and as it says in the Note: "Currently, only a subset of Zephyr’s Bluetooth APIs is available over Bluetooth nRF RPC. For more details about the limitations, see the API documentation of the Bluetooth nRF RPC library."

Unfortunately it's been "Currently" for quite some time, so I don't expect it will change anytime soon.

An alternative approach you may consider is to switch to the nRF54L15, which provide a risc-v CPU that can run whatever you want, completely uninterrupted:
https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/vpr.html

You can then use mbox to transfer data between the application core and the risc-v cpu core:
https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/hardware/peripherals/mbox.html

Example project:
\zephyr\samples\drivers\mbox

Personally I would have checked out the nRF54L, since it's our latest development platform, with a range of devices in the roadmap (reach out to someone in sales if there are specific features you are interested in that is not part of the nRF54L15, use contact us and sales related questions: https://www.nordicsemi.com/About-us/Contact-Us). LLPM is also supported by the nRF54L, which have far better latency than normal BLE due to 7x interval. Of course if you have got far in development with the nRF5340 that is not an option.

Hope it helps,
Kenneth

RE: Is there a way of running BLE on the network core only on nRF5340?

nfbe — Mon, 10 Mar 2025 18:12:05 GMT

Hi Kenneth,

thanks for your reply. I was not expecting to see any large jitter (>> the connection interval) for my device, but I actually do observe it. The reason for choosing nrf5340 was to decouple the transmission via standard BLE (or other radio protocols) from my time critical application, which essentially requires to be in the range of 1ms in a loop reading sensors and every now and then sending a notification. In >>99% of the cases everything on the application side works as expected and the notification takes between 50 and 120 µs on the app core. Unfortunately every now and then the notify takes far longer even though I have only the main thread running from my application side and a cyclic hardware interrupt firing regularly but not firing in the first 200µs after calling the notify... so this interrupt should not be the original cause of my jitter problem.

I implemented a simple IPC communication from app core to net core instead of the notify and that runs "rock steady" with no jitter to speak of and no outliers always taking less than 50µs on the app core. Of course I needed to replace the net-core by an IDC-service code... which gave me the opportunity to better understand the communication and also to use some gpios on the net core side for oscilloscope "debugging".. and, I obviously disabled BLE...

=> so, if I would be able to either:

a) debug and measure the communication between app core and net core in the BLE case (which would mean changing the hci_rpmsg code to e.g. control some gpio pins for oscilloscope measurements) I might be able to better understand the source of the problem.

or preferably:

b) use my simple IPC communication to decouple app core and net core and then have something different from the "standard" hci_rpmsg on the net core, I would be able to keep my inter core communication absolutely the same no matter which type of radio protocol I implement on the net core (standard BLE, llpm or ESB - if possible on the nrf5340 net core only) as alternatives for different communication partners.

I would like to try your suggestion on adjusting priorities, if that could solve my problem in case a). Since my work loop code runs in the main thread, I assume it will have priority 0, because I do not actually assign a priority to it. That leads to two questions

=> how do I change priority? I guess I would need to create a thread to run my application's critical loop and assign some priority to it, or can I change the priority of the main thread?

=> since whatever is interrupting the notify function is not a thread or interrupt I explicitly created from my application side, I assume it is somehow related to a zephyr driver ... maybe BLE?
--> So: how do I find out, what is causing the effect
--> So: which priority level should I assign to my work loop?

To give you some background to my latency and jitter requirements:

The possible applications of my device depend on the total transmission latency of the chain. It would be top notch to reach something stable below 3 ms, most applications would still tolerate 10 ms , which could be reached with a 7.5ms connection interval, if communication errors would occur next to never and a few use cases will also work with up to 20 ms.
If it would be possible to have a choice of protocol depending on the capability of the radio-communication partner, it would be ideal for my device.

In short:

1) I would like to reach latencies and jitter both in the range of 1 ms (ESB or llpm) to be able to stay below 3 ms always.

2) I absolutely need to reliably have maximum latencies of 1 connection interval + 3 ms (BLE)

With a BLE central capable of 7.5 ms connection interval and no other communication going on in parallel, I currently see the following (this central can reliably communicate with a BLE peripheral in less than 10ms):
very often the transmission takes <(1 connection interval + 3ms), but not always... sometimes the transmission needs up to (2 connection intervals + a little bit) using my application on a nrf5340dk or on my own custom device.

Unfortunately I do not exactly understand your reference to the nrfx drivers. The links do not really lead to pages with a detailed description but a list of all drivers supported. Could you please tell me, which drivers would be relevant to solve my problem of core communication and/or BLE on the nrf5340?

Thanks for your advice.

Regards,

Jens

RE: Is there a way of running BLE on the network core only on nRF5340?

Kenneth — Mon, 10 Mar 2025 11:58:24 GMT

Hi Jens,

The netcore should handle all the realtime requirements of the BLE connection, so even though the host still run on the application, there should be no realtime requirement by the host that should prevent the application to have the highest priority for the nRF5340, so if you observe that the application interrupt do not behave as you expect (e.g. have jitter), I suspect you may need to adjust the priority of the thread you want to run in the application. How much jitter do you observe or how much jitter can you allow?

If you want to have even better control you may need to look at using the low level nrfx drivers:
https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/nrfx_drv_supp_matrix.html
https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/nrfx_examples_desc.html

Kenneth