nRF5340 dual CPU development without NCS

[Tamas Selmeci]

Hello!

I've been investigating NCS for several days and come to the conclusion that we don't definitely have to use it for our developments. By the way, it'd be way too difficult to integrate the whole NCS into our existing build system, as NCS (apart from nRF SDK) is a build system too, which is very incompatible with ours.

I've successfully found the NRF MDK package with linker scripts for both the net and app processors. This implies me that it's possible to develop bare metal (OS-less) programs for either processor core in nRF5340. In the first phase we don't plan to develop BLE applications, so in practice perhaps we don't need to use e.g. the net core at all.

Later, when the net core will be in our focus, with the help of IPC, MUTEX etc. peripherals, we can even develop our own IPC solutions to let the two cores communicate with each other. Or maybe we can make use of OpenAMP and other related libs from NCS, unless they refuse to compile and work out of Zephyr.

A research on a FreeRTOS for the application core is also in our interest.

These all above seem to be pretty logical and "doable" to me, but please correct my misconceptions, if any.

The tricky part comes in by the need of BLE. SoftDevice BLE controller on net processor, what BLE host to use on app processor? On nRF52 I can't recall any BLE host, I just called API functions. Can this be the same on nRF5340? But to call the API functions (nrfxlib, sdc.h etc) is some kind of IPC needed, isn't it? Is the SoftDevice tied to OpenAMP / nRF-RPC? If so, can these libs be used out of Zephyr? Furthermore, SoftDevice is just a precompiled lib (.a), it definitely needs az execution environment (a simple mainloop or anyhing much more complicated) to run on the net processor and to be able to process the requests from the app processor, or to signal events to app processor etc.

So SoftDevice is considered to be RTOS-agnostic, but may need some "wrapper" to be able to run correctly, as flashing a simple .a to the net processor flash won't give a good solution to this problem ;)

Am I on the wrong path? Any thoughts on these all above?

Thanks, regards,

[Einar Thorsrud]

Hi,

as NCS (apart from nRF SDK) is a build system too, which is very incompatible with ours.

Is it not possible to keep things separate? To what extent do you need to integrate the build system of the nRF application to other parts?

I've successfully found the NRF MDK package with linker scripts for both the net and app processors.

Yes, the MDK consists of startup files and register definitions, so using only that means that you will have to do more or less everything yourself.

In the first phase we don't plan to develop BLE applications, so in practice perhaps we don't need to use e.g. the net core at all.

If you might use BLE in a later phase I would take that into account right now.

These all above seem to be pretty logical and "doable" to me, but please correct my misconceptions, if any.

You are right that it is doable, but the only thing we support on the nRF53 series is the nRF Connect SDK, so you will be on your own. And by not using any of what we provide you will have to do a lot of work yourself. I would question if that is a sensible use of resources, but if you have a lot of time/money/engineering hours to spend, perhaps it could be in some special cases.

The tricky part comes in by the need of BLE. SoftDevice BLE controller on net processor, what BLE host to use on app processor?

The SoftDevice Controller is RTOS independent, so you can in principle use it with any other Bluetooth host that has a HCI interface. We use the Zephyr host, but there are others out there that you can use on your own risk and without support. With the reasoning from above, I would recommend using the Zephyr RTOS with the Zepyr Bluetooth host, as part of the nRF Connect SDK. But it is up to you.

On nRF52 I can't recall any BLE host, I just called API functions.

The old SoftDevice was different, as that was a full integrated Bluetooth stack that also included the host. 

Can this be the same on nRF5340? But to call the API functions (nrfxlib, sdc.h etc) is some kind of IPC needed, isn't it? Is the SoftDevice tied to OpenAMP / nRF-RPC? If so, can these libs be used out of Zephyr?

We recently introduced a samplet that is intended to run on the network core that includes both the host and controller, and uses remote procedure calls (IPC), which could be relevant in this case. See Bluetooth: Host for nRF RPC Bluetooth Low Energy.

Furthermore, SoftDevice is just a precompiled lib (.a), it definitely needs az execution environment (a simple mainloop or anyhing much more complicated) to run on the net processor and to be able to process the requests from the app processor, or to signal events to app processor etc.

So SoftDevice is considered to be RTOS-agnostic, but may need some "wrapper" to be able to run correctly, as flashing a simple .a to the net processor flash won't give a good solution to this problem ;)

I am not sure about what the question is here. Perhaps you can elaborate?

Am I on the wrong path? Any thoughts on these all above?

It is difficult to say. But even very large users of nRF devices typically migrate to the nRF Connect SDK and use what we provide instead of trying to do too much on their own. I would have a very good reason for throwing out the work we have put into the SDK in favor of your own home grown solutions.

[Tamas Selmeci]

Hello!

Thanks for your answer.

Einar Thorsrud said:

not possible to keep things separate?

Not really, we're developing not only BLE programs, BLE is just an additional feature in some of our products. And the existing work must be kept (this means dozens of PCBs with various MCUs). And our future BLE programs will have to rely on our existing work (e.g. patented libraries etc). Therefore maintaining multiple build environments is something we want to avoid. 

The best option I've seen in the NCS documentation is the out-of-box build of our BLE applications. Unfortunately our applications are not just small programs with one or two C files, but large programs, they depend on many other libraries, configuration files etc. developed by us, that's why after investigating NCS for at least 3 entire days I'm still not sure the integration is simply doable. But I'm not really experienced with NCS. Can NCS build system be told to compile libraries etc. in various external directories?

Einar Thorsrud said:

the only thing we support on the nRF53 series is the nRF Connect SDK, so you will be on your own

It has been clear from the very beginning.

Einar Thorsrud said:

On nRF52 I can't recall any BLE host, I just called API functions.

The old SoftDevice was different, as that was a full integrated Bluetooth stack that also included the host. 

I had a quick glance at nrfxlib/softdevice_controller/include/*.h files. If we decide to use SoftDevice directly, is it the API we have to use? In other words, does the Zephyr Bluetooth host make use of these functions via NRF RPC, am I right?

Einar Thorsrud said:

We recently introduced a samplet that is intended to run on the network core that includes both the host and controller, and uses remote procedure calls (IPC), which could be relevant in this case. See Bluetooth: Host for nRF RPC Bluetooth Low Energy.

The source is just a printk and this all tells me nothing about how the RPC is working, or how it should be used in practice. OK, I see RPC is enabled in the configuration, but this doesn't help me to understand how to RPC between net core (with SoftDevice) and app core (with a Bluetooth host or with our custom solution).

Einar Thorsrud said:

I would have a very good reason for throwing out the work we have put into the SDK in favor of your own home grown solutions.

The point is that somehow we must be able to use nRF5340's new features without throwing away our existing work at all (this means our build system, libraries, configs, applications), as they're too valuable. At this point of investigation the BLE feature is the show stopper, because everything else is rather simply supportable by nrfx/MDK etc out of NCS's scope. We'll see. Nevertheless I'm going on with my investigation and wait for your advices ;)

[Einar Thorsrud]

Hi,

Tamas Selmeci said:

But I'm not really experienced with NCS. Can NCS build system be told to compile libraries etc. in various external directories?

I am not sure if you want to build linkable libraries, or want o include external libraries, or something else. But the build system is quite flexible and this is all possible. The NCS build system can be used to build libraries as well as end applications. And this can reside out of the SDK tree if you like (you can refer to the out of tree driver sample, which shows basically this). You may also be interested in some of the other Application development samples.

Tamas Selmeci said:

I had a quick glance at nrfxlib/softdevice_controller/include/*.h files. If we decide to use SoftDevice directly, is it the API we have to use? I

The SoftDevice controller is just the Bluetooth controller, so if using that, you will need a Bluetooth host and the interface is HCI, which is standardized by the Bluetooth SIG. That brings us to the alternative:

Tamas Selmeci said:

The source is just a printk and this all tells me nothing about how the RPC is working, or how it should be used in practice. OK, I see RPC is enabled in the configuration, but this doesn't help me to understand how to RPC between net core (with SoftDevice) and app core (with a Bluetooth host or with our custom solution).

This implements a full Bluetooth host + controller, but everything is pulled in by the build system, so you should look at the prj.conf from the sample and what that includes. Specifically CONFIG_BT_RPC and CONFIG_BT_RPC_HOST are relevant in this case. To find the code the simplest is to search in the code for the relevant config, and that would lead you to the RPC code in under nrf/subsys/bluetooth/rpc/. This is what would run on the net core though, so the only thing you would have to implement in your application is the other end of this, see the API doc for the RPC Bluetooth API.

Tamas Selmeci said:

The point is that somehow we must be able to use nRF5340's new features without throwing away our existing work at all (this means our build system, libraries, configs, applications), as they're too valuable.

It still seems a bit odd to me that you should have to throw away your existing libraries just because you use NCS on this project (assuming they are written in an SoC and RTOS agnostic way). I mean, a big chuck of nRF Connect SDK is generic libraries - large and small - that are just integrated and used there, but which was not written with Zephyr in mind originally.