CPUAPP-CPUNET Firmware

RE: CPUAPP-CPUNET Firmware

dario.sortino — Thu, 22 Dec 2022 09:43:39 GMT

I think that there is a subtle difference between what you are explaining (and that it actually does), and the "receiving speed of data coming from the other core", mostly because we are calculating the data output rate within the core. I mean, we are not reading the buffer in the network core and calculating the speed of the application core (and vice-versa), the example instead sends from the appcore and calculate the throughput within that core (and vice-versa). There is no actual exchange of the "p_payload" data between the cores, and for this reason, I think the example is misleading in some way: each core prints the speed of data coming out of the same core.

Nevertheless, playing with the code I was able to exchange data between the cores, so the ticket can be closed. Thank you so much for the help provided!

RE: CPUAPP-CPUNET Firmware

AstralStorm — Wed, 21 Dec 2022 12:51:14 GMT

Why, the example does exactly what it has to do.
It has a known packet size and calculates packets per second that the buffers can take on the other end after receiving an acknowledgment.
Of course this is maximum throughput - network core actually doing something with the packets will make it slower.
It is one way signalling too, if you want to write a loopback you'll have to write your own test.

What it does not do is use zero copy transfers, which could make it faster still.
Also it can use ICMsg backend and not RPMsg backend if you pick the different configuration.

RE: CPUAPP-CPUNET Firmware

dario.sortino — Wed, 21 Dec 2022 12:23:41 GMT

I am quite confident to say that the example doesn't do what it is supposed to do. It doesn't print the throughput of data coming from the other core, because the callback for the received data is never used correctly. It just prints the throughput of output data from the same core.

I wonder if there is a better place to report this issue (apparently there is no Issue tab on nRF Connect Github page).

[quote userid="117283" url="~/f/nordic-q-a/94914/cpuapp-cpunet-firmware/401476"]And it says that "both application and network cores periodically print out the receiving speed of data that was sent by the other core[/quote]

RE: CPUAPP-CPUNET Firmware

dario.sortino — Tue, 20 Dec 2022 10:35:17 GMT

I was exploring the IPC Service example here developer.nordicsemi.com/.../README.html

And it says that "both application and network cores periodically print out the receiving speed of data that was sent by the other core".

Although I think I have understood the configuration of the example, it's not quite clear to me how it is able to print the speed of data.

In the code https://github.com/nrfconnect/sdk-nrf/blob/main/samples/ipc/ipc_service/src/main.c (that is executed from both cpuapp and cpunet in the default build configuration), I just find a thread defined that run the "check_task", but it prints info from the p_payload global variable. I don't get where this p_payload is populated with information that comes from the other core.

RE: CPUAPP-CPUNET Firmware

AstralStorm — Mon, 19 Dec 2022 16:10:32 GMT

You are on the right track. Normally you do not have to care about OpenAMP at all if you use only the IPC services - these hide the thing from you.

RE: CPUAPP-CPUNET Firmware

dario.sortino — Mon, 19 Dec 2022 14:09:23 GMT

I am finally getting a grasp on how to write for the Network core. So far I'm successfully building and flashing FW on the DK and I can see output from both cores.

For the data exchange part, I'm still trying to figure everything out, but so far I think the best and easiest way to share data is by using directly IPC services docs.zephyrproject.org/.../ipc_service.html. Am I on the right track?

I don't get the whole backend part you were talking about. The OpenAMP RPMsg is something I need to care about if I use the bare ipc drivers?

RE: CPUAPP-CPUNET Firmware

AstralStorm — Fri, 16 Dec 2022 09:16:18 GMT

The multicore example is indeed the way to go. Put whatever you want to run on the network core in the cpunet directory. If you want to run bluetooth, copy hci_rpmsg (which is also in samples) in there and start coding from that.

Unless you want cpunet to just run Bluetooth. In which case using the default hci_rpmsg setup is the way to go.

You can adjust the example later to work with Secure Bootloader if necessary.

Be mindful that CPUNET has only 256 KB of flash and 64 KB of RAM by default. Changing that is possible but not too easy. Not a lot can fit in there. It also only has some hardware routed to it.
See here for which hardware is available on cpunet: docs.zephyrproject.org/.../index.html

RE: CPUAPP-CPUNET Firmware

dario.sortino — Fri, 16 Dec 2022 09:12:58 GMT

Yes, I am very confused about how things work, and I hope to make things clear.

I had a look at the link you provided me, and I went through the multicore example so that I can try to get it.

What I'm getting is that the CMakeLists.txt in the aci folder tells Zephyr to build what is inside the cpunet folder for the Network core. In the example, we don't have anything written in the cpunet folder, but a Cmake that is pointing to the src/main.c. This can be possible because of the definition of a Zephyr module (module.yml). At this point I think I can write a main.c that will be pointed by the cpunet/CMakeLists.txt that execute whatever I want to execute in the Network Core.

As naive as it may sounds, I'm just trying to figure out where to write code for the Network core and where to write code for the Application, then flashing everything in my board 😃

RE: CPUAPP-CPUNET Firmware

AstralStorm — Fri, 16 Dec 2022 08:44:21 GMT

You are mixing things up. An application is not the same as a main function or a module.

You *can* build separate applications. You do not *have to*.
By default, NRF Connect SDK build one multi-image application, with one image per core.
There is also a possibility to build a bootloader as a separate image in an application, used most typically for DFU or similar update schemes.

These are not necessarily separate in any way, they can share headers or other files, and certainly can share Zephyr or other parts of the SDK.

There are multiple main functions in such an application and two or more separate hex files are merged together.

One of the modules runs on CPUNET, the other runs on CPUAPP . Both are built at the same time in a multi-image application.

There are also applications that run nothing on CPUNET or nothing on CPUAPP.
(The example for multicore application in fact runs a big nothing on CPUAPP.)

Now provided you want to run code on both, you will have to create two modules. They can be built separately as separate single image builds, which may mean they do not share any code (but they still can), or together as part of a multi-image build in which case they always share the SDK.

This bit might help explaining the difference between an application and a module: developer.nordicsemi.com/.../ug_multi_image.html
And this bit might explain the separate bootloaders: developer.nordicsemi.com/.../README.html

The non-default separate application per core build is a bit harder to configure. You must ensure the bootloader settings are correct... It is not supported by Nordic.

RE: CPUAPP-CPUNET Firmware

dario.sortino — Fri, 16 Dec 2022 08:39:55 GMT

When you say sample for CPUNET, it means that i should flash the example in the Network core and flash another, custom application in the Application core? So in the end I should write two main.c that needs to be built each with their own dependencies, am I getting it right?

RE: CPUAPP-CPUNET Firmware

AstralStorm — Thu, 15 Dec 2022 15:48:50 GMT

There are multiple ways to build the application for both cores.

It partly depends on whether you build the Secure or Non-Secure variant, and it depends on whether you build separate images or (the default) multi image build.

Nordic examples include a prebuilt app for CPUNET called hci_rpmsg which implements a Bluetooth controller communicating via OpenAMP RPMSG protocol.

The kernel option to disable it in CPUAPP is: CONFIG_NCS_INCLUDE_RPMSG_CHILD_IMAGE=n
If you put that in prj.conf (or otherwise specified kernel config file) the default child image will not be built and included.

The default hci_rpmsg can be configured by creating child_image/hci_rpmsg.conf file with Zephyr kernel configuration options. You probably want CONFIG_LOG=y - the defaults will output to the second UART. Configure it like you would logging for CPUAPP.
You can also use RTT output for that core, but attaching there does not work properly with Non-Secure mode applications and will interfere with the execution.
If you build a Non-Secure variant, one of the UARTs is taken by default for logging from TF-M loader. There are kernel options to disable it.

You can include a custom CPUNET image with some CMake trickery including a zephyr module, see nrf/samples/nrf5340/multicore.
The trickery is required to prevent an infinite include loop.

hci_rpms uses Zephyr IPC services with OpenAMP RPMsg backend to implement the communication between the cores, a pretty powerful toolkit which is too much to describe in the simple post.

The details of the backend are configured using the Device Tree, which you can find in the various nrf5340 related device tree dtsi files in Zephyr.
These use nordic,mbox-nrf-ipc for the low level MBOX module configuration and zephyr,ipc-openamp-static-vrings.for the higher level OpenAMP RPMSG configuration which specifies that Mbox.
IPC module is described here: https://infocenter.nordicsemi.com/topic/ps_nrf5340/ipc.html
But unless you want to do it low level, use Zephyr IPC services instead: docs.zephyrproject.org/.../ipc_service.html

Generally since it is CPU-specific rather than board specific you should not need to change them, unless you want to use some sort of external memory for the IPC or need to make the buffers big, whihc would require changing the sram0_shared definition.

Another example using OpenAMP RPMSG would be in nrf/applications/nrf5340_audio - more complicated, different design.