nRF5340 - Accessing Shared Memory

RE: nRF5340 - Accessing Shared Memory

Elfving — Wed, 29 Mar 2023 13:33:47 GMT

Hello and sorry about the delay. I must've overlooked this case for a while.

[quote user="jmilliken"]So now we have established a shared memory region, okay, so far so good.[/quote]

Yes, this is where it is defined.

The documentation on what is mentioned in the snippets you have from device tree there could arguably be improved, but there is a lot available. Here is a bit on the "ipc-openamp-static-vrings" devicetree binding, and there is apparently also a sample on it. And here is a bit on the mboxes.

[quote user="jmilliken"]also, where are the linker files?[/quote]

Build/zephyr/

[quote user="jmilliken"]How do each of the programs use this memory region?[/quote]

Well that depends. IPC might be the most common, though here is also an example of something a bit more basic: this module is used to write a single struct to a RAM area which is known by both cores. The appcore writes here, and the netcore reads here.

In the case of IPC, the PS probably describes this best (Section 7.16).

The IPC indicates to the other core that there is new data available to pick up. The actual data exchange is handled by Open Asymmetric Multi-Processing (OpenAMP). Zephyr includes the OpenAMP library, which provides a complete solution for exchanging messages between the cores. The IPC peripheral is presented to Zephyr as an Interprocessor Mailbox (IPM) device. The OpenAMP library uses the IPM SHIM layer, which in turn uses the IPC driver in nrfx.

[quote user="jmilliken"]const struct device *hci_ipc_instance = DEVICE_DT_GET(DT_NODELABEL(ipc0));[/quote]

That creates a pointer to the device driver. There is more on that here.

[quote user="jmilliken"]How is peripheral_uart using the ipc system and the shared memory?[/quote]

I believe this happens in the dts file nrf5340_cpuapp_common.dts:

REgards,

Elfving

RE: nRF5340 - Accessing Shared Memory

jmilliken — Mon, 13 Mar 2023 01:47:06 GMT

Another notable thing - looking at both zephyr.map files, neither file seems to have any data structures living in the shared memory range. Shouldn't I see some overlapping variables at 0x20070000 vicinity?

RE: nRF5340 - Accessing Shared Memory

jmilliken — Sun, 12 Mar 2023 20:54:09 GMT

Hello. I am revisiting this topic lately and still need some clarification. I am looking at the device tree includes and can see that both the peripheral_uart project and the hci_rpmsg project eventually include "nrf5340_shared_sram_planning_conf.dts" which gives the following:

chosen {
/* shared memory reserved for the inter-processor communication */
zephyr,ipc_shm = &sram0_shared;
};

reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

sram0_shared: memory@20070000 {
/* SRAM allocated to shared memory */
reg = <0x20070000 0x10000>;
};
};

So now we have established a shared memory region, okay, so far so good. Next, I see in each device tree, somewhere the following eventually gets included:

ipc0: ipc0 {
compatible = "zephyr,ipc-openamp-static-vrings";
memory-region = <&sram0_shared>;
mboxes = <&mbox 0>, <&mbox 1>;
mbox-names = "tx", "rx";
role = "host";
status = "okay";
};

So now we have the ipc module attached to the shared memory region. However, here is where I get lost. How do each of the programs use this memory region? Normally I would expect to see something like __attribute__ used in front of a variable to denote that it should be placed in that region by the linker (also, where are the linker files?).

In the hci_rpmsg main.c, I can at least see some references to this, such as:

const struct device *hci_ipc_instance = DEVICE_DT_GET(DT_NODELABEL(ipc0));

and:

const struct device *hci_ipc_instance = DEVICE_DT_GET(DT_NODELABEL(ipc0));

But how does this link back to the sram0_shared region? Also, how are the mailboxes used in this context? How large are the mailboxes (i.e. where is the mailbox size determined).

Now, on the other end, the main.c from the peripheral_uart project, I don't see any references to the ipc system at all. This leads me to believe that the bt_nus is somehow uses this information behind the scenes, but I'm so far unable to follow the function calls back through to anything that makes this explicit. How is peripheral_uart using the ipc system and the shared memory?

-Jamie

RE: nRF5340 - Accessing Shared Memory

jmilliken — Wed, 20 Jul 2022 00:59:53 GMT

Thank you. the DevAcademy link looks like a very good starting point. I will work my way through that.

RE: nRF5340 - Accessing Shared Memory

Elfving — Tue, 19 Jul 2022 12:35:58 GMT

Hello again,

[quote user=""]Coming from STM32 and FreeRTOS, so the Zephyr learning curve is feeling steep so far. Any help is appreciated.[/quote]

That is very understandable. To start off, I would recommend you to take a look at our DevAcademy, which will give you a basic understanding of Zephyr.

You are right in that the inter-core communication is happening using shared memory. This is unfortunately a complex topic, and difficult to give basic example of. The documentation on the nRF5340 and the documentation on working with it describes a little bit about it. And this previous case of mine describes a bit more. Taking a look at the examples I linked to there will probably be beneficial, and answer your second question.

When it comes to how this is done in a project like the peripheral_uart sample, I would have to get back to you.

Regards,

Elfving

RE: nRF5340 - Accessing Shared Memory

Elfving — Thu, 14 Jul 2022 10:23:45 GMT

Hello Jamie,

I will get back to you on this. Note that we have entered the summer holiday period in Norway so staffing is low, some delayed response time should be expected.

Regards,

Elfving