nrf5340 BLE + custom code on NET core

[Tamas Selmeci]

Hello!

On a nrf5340dk devboard with NCS-2.4.1 I'd like to run the BLE beacon sample of Zephyr (zephyr/samples/bluetooth/beacon). It's not a big deal to compile and burn into the flash, and it's running. If I'm not wrong, the layout is something like this:

• APP core runs a Zephyr instance + BLE host (configurably Zephyr or Nordic) + BLE HCI;
  • BLE HCI communicates with the SoftDevice controller on NET core via some kind of RPC, I think through shared memory;
  • APP core can run my custom code too (by editing main.c etc);
• NET core runs a Zephyr instance with different config than on APP core;
  • NET core runs the SoftDevice controller, which is responsible for low-level, timing critical BLE atomic operations;
  • NET core is on the other side of the RPC channel, processes requests from APP core (BLE host);

Please confirm if the above are at least roughly/conceptionally true...

Now these're all nice and good, but I want to utilize the peripherals on the NET core too. In other words, I want to write my custom code to NET core too by keeping the existing SoftDevice/RPC structures. And I simply haven't found any sample which would cover this, nor any reference here in the Q&A forum. What is not clear:

• how does the build system solve automatically that by having CONFIG_BT=y it compiles hci_rpmsg as a child image;
  • from which components (sources) does it generate the final NET .hex?
• where's the main(...) function of the NET core app running the BLE beacon sample app?
• how can I add my custom code without destroying existing BLE code on NET core? As a start, I'd be extreme happy just to printk(...) something in a loop while BLE beacon is running;

nrf/samples/multicore/hello_world is stated to run on both cores, but in fact for NET core no code is generated. Anyway, if it compiled to NET core too, it wouldn't even demonstrate how to develop to both cores when BLE funcionality is also required.

I'd also be very happy to get an empty BLE beacon project which keeps on printk(...)-ing some sort of string on the NET core, so I could continue my development by inspecting that.

Thanks, regards,

[Hung Bui]

Hi Tamas, 

It's actually pretty easy to do. 
What you need to do is to find a simple BLE sample, my suggestion is to use peripheral_lbs . Build it for nrf5340dk_nrf5340_cpunet. When building a BLE application for the netcore, the hci_rpmsg will not be included. 

Then you use empty_app_core sample to build an empty app core that forward all the peripheral control to the netcore (you will need to chang this later as you will use app core for something). Then build and flash it for the nrf5340dk_nrf5340_cpuapp 

You may need to recover both the application core and netcore before flashing. 

After that you should be able to see the peripheral_lbs advertising. 

Another option if you don't want to run everything on the netcore and the main application still on appcore, is to take a look at the host RPC sample. With this sample, you use RPC protocol instead of HCI and both the host and controller running on netcore, only the BLE service and other part of the application (peripheral_uart for example) is running on app core

[Tamas Selmeci]

It's sufficient if all BLE components (host, controller) are running on the NET core, so I've followed your first proposal: compiled BLE beacon sample to NET core, then compiled hello_world sample to APP core, enabled the NET core power Kconfig option in the hello_world sample and flashed them separately. This is the scenario I want to work with.

As per communication between CPU cores, nrf_rpc or mbox (nrf_rpc preferred) seems to be adequate, am I right?

[Hung Bui]

Hi Tamas, 
My suggestion is to use empty_app_core first before you try with the hello_world. It's just to make sure the netcore application can run without any modification. After that you can start experiment with hello_world. 

For communication between the cores, yes, nrf_rpc is recommended.