Sample for network core of nRF5340

[Hiihtaja]

Hi !

I have own radio driver for nRF52840  ( nRF5 SDK based, fully interrupt driven ) and would like evaluate it on network core of  nrf5340. App core can be empty.

Could you suggest sample what have minimal zephyr start up code and example how-to register interrupt handlers for radio and timers.

It can help for me to port my driver because it is just direct access to registers of peripherals and etc.

You have standard radio drivers what implemented for support serialization and multiple different nRF52/53 MCU and it is not so clear for beginning.

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene,

I think the closest thing you what you ask for is the ESB sample. That can run on the nRF5340 nework core without any serialization or other things related to the app core. You will need the empty app core sample on the app core though, as the app core starts first, and needs to start the net core. You can look at the ESB library implementation (nrf/subsys/esb/) for an exmaple on how to use the radio directly.

Einar

[Hiihtaja]

Hi Einar !

Thank you !

Could you answer few common questions about network core frameworks  as well.

1.  Does all nrfxlib have closed sources ? Network core actively used those but not always clear what there are doing.

2. Does MPSL library is need if I have plan to use  different FEM devices ? Or  MPLS library is flexible and with proper initialization I can use required part only and it not consume extra HW peripherals.

3. I need IPC services ( IPC sample based) at some point and as result should use Zephyr OS on network core.

  But what exact Timers and other peripherals are occupied by Zephyr OS version for network core ?

4. I can see your radio drivers used RPC calls and  RPC messages for control drivers on network core. Not always clear what is recommended/best way. Looks like IPC messages asynchronous and network core can perform expected setting with small delay after message is received. But calls be done faster. Or those are very similar and just wrapped to different API ?  Also what it technique you use if radio driver should work on nRF52 and nRF53 network core. May be it is explained somewhere in more details ?

5. I can see nrf52840 and nRF5340 peripherals are quite similar ( in case of radio, timers, PPIs) and others what need to implement some radio drivers. But may be you have some migration guide what can explain actual difference ?

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene

Hiihtaja said:

1.  Does all nrfxlib have closed sources ? Network core actively used those but not always clear what there are doing.

Yes, nrfxlib is a collection of closed source libraries. You can refer to the nrfxlib documentation for an overview of what is contains.

Hiihtaja said:

2. Does MPSL library is need if I have plan to use  different FEM devices ? Or  MPLS library is flexible and with proper initialization I can use required part only and it not consume extra HW peripherals.

MPSL is always needed when yo use the SoftDevice Controller, which is the link layer of the Bluetooth stack. It has support for FEM devices, but you do not need to use any. But if you use your own radio driver directly and nothing else, I would assume you also do not use MPSL? This is generally a layer that is there to provide multiprotocol support (to share radio access between several different stacks).

Hiihtaja said:

But what exact Timers and other peripherals are occupied by Zephyr OS version for network core ?

The resources and peripherals used by Zephyr are generally configurable, and the most important is an RTC. However, if you use MPSL, that is not the case. You can refer to the Timeslot documentation for a list of what is available in a timeslot (but not normally when using MPSL).

Hiihtaja said:

4. I can see your radio drivers used RPC calls and  RPC messages for control drivers on network core. Not always clear what is recommended/best way. Looks like IPC messages asynchronous and network core can perform expected setting with small delay after message is received. But calls be done faster. Or those are very similar and just wrapped to different API

Fundamentally IPC works the same way at the lower levels regardless. There is shared memory, and the IPC peripheral that is used to generate events on the other core. And you can build different protocols with different APIs on top of that.

Hiihtaja said:

Also what it technique you use if radio driver should work on nRF52 and nRF53 network core. May be it is explained somewhere in more details

With an nRF52 it would be different, as it would not be IPC but communication via some other (serial) interface. There are some samples on how to do communication both, IPC (for instance the IPC service sample) and other serial communication via UART or other. I cannot say what would fit best in your case. You would need to find what works in your application and your use case.

Hiihtaja said:

5. I can see nrf52840 and nRF5340 peripherals are quite similar ( in case of radio, timers, PPIs) and others what need to implement some radio drivers. But may be you have some migration guide what can explain actual difference ?

There is no migration guide that explains the difference. However, you are right that the peripherals are for the most part the same (with a number of minor changes). The primary difference between the nRF52 and nRF53 is the other parts of the device, like the multi core architecture and CPU (M33 vs M4).

[Hiihtaja]

Hi Einar !

Softdevices are not in use for sure.

May be I should look  what kind of APIs/driver available for support FEM without MPSL library or I should write it by myself ?

About Zephyr peripheral usage. If I take IPC sample https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/ipc/ipc_service/README.html

as basis,

how I know ( and change if need) what kind of timers are used for application and network core ?

I understand difference between  nRF52 and 53 in case of cores. But I think it is quite typical  flow when working on nRF52 application ( os less ) should be executed on nRF53 network core almost as it is. It should be possible to do without significant changes.  

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene,

Hiihtaja said:

May be I should look  what kind of APIs/driver available for support FEM without MPSL library or I should write it by myself ?

We do not provide any such drivers (other than the support in MPSL which is not relevant for you), so yes, that will be up to you.

Hiihtaja said:

how I know ( and change if need) what kind of timers are used for application and network core ?

Zephyr itself does not use any timers, only an RTC for system tick and keeping track of time. Zephyr use RTC1 by default. You can disable it with CONFIG_NRF_RTC_TIMER (though then you will have no time source), or modify the implementation in nrf_rtc_timer.c if you really need to change it (I would just use another timer in your code instead, though).

Hiihtaja said:

But I think it is quite typical  flow when working on nRF52 application ( os less ) should be executed on nRF53 network core almost as it is. It should be possible to do without significant changes.  

Yes and no. I am not sure how common it is though, as if you only need one core you probably would not migrate from the nRF52 series. That said, while most things are very similar, there are a number of minor changes as even though it is fundamentally the same peripherals on the same process, there are fixes and improvements here and there. But as said, there is no migration document. Generally, if you work with direct register access you need to digg into the chapters for those peripherals in the nRF5340 product specification in order to understand it and handle any differences. But where you use higher level drivers, most changes are handles for you without you having to know or care about it.