Device Tree overlay ipc icmsg sample

[dario.sortino]

Hello everyone.

I was trying to integrate the ipc_service sample in my application. It was working all fine and I was able to set up and link the endpoint in my code. I then tried to run a clean build, and I don't know why everything broke: when I try to execute ipc_service_register_endpoint, this happens, the board resets and keeps doing it forever.

 

Thinking that is a matter of memory position, I found out that my compiled devicetree output for the application core has a reserved-memory node like this

reserved-memory {
        #address-cells = <1>;
        #size-cells = <1>;
        ranges;
        sram0_image: image@20000000 {
                reg = <0x20000000 DT_SIZE_K(448)>;
        };

        sram0_s: image_s@20000000 {
                reg = <0x20000000 0x40000>;
        };

        sram0_ns: image_ns@20040000 {
                reg = <0x20040000 0x30000>;
        };

        sram_rx: memory@20078000 {
                reg = <0x20078000 0x8000>;
        };

};

Instead of 

reserved-memory {
        sram_tx: memory@20070000 {
                reg = <0x20070000 0x8000>;
        };

        sram_rx: memory@20078000 {
                reg = <0x20078000 0x8000>;
        };

};

Network core side instead, the devicetree seems ok, but I still encounter the error at endpoint registration time.

I am quite lost and I don't really know how to proceed, since this problem appeared point-blank when I tried to build from zero once again.

[dario.sortino]

That would be great. I'll try to remove all the external dependencies.

[Vidar Berg]

Sounds good. I have made the ticket private now in case you do not want your project to be made public.

[dario.sortino]

DemoStation.zip

I included also the build folder (I built for nrf5340dk_cpuapp).

Sorry, just realized that I forgot to briefly explain what is happening:

The NetCore constantly sends data via ESB without ACK. So in the CPUNET COM port, you will see a lot of TX SUCCESS from the logger. Every 100 ms the main loop will also send data to the other core.

In the AppCore instead, you are just standing still listening to messages incoming from the other core, printing a "Message Received" in case it does. The problem is that it never does print such a message.

[Vidar Berg]

Thanks for sharing your project. It looks like the only problem was that you had placed an "idle" loop at the end of main() in your application. It is better to let the program return from main so the Zephyr idle thread can be run.

Fullscreen 4857.diff.diff Download

--- "DemoStation (1)/src/main.c"	2023-02-14 12:10:20.000000000 +0100
+++ DemoStation/src/main.c	2023-02-14 14:56:27.258293905 +0100
@@ -30,9 +30,9 @@
 	//LOG_INF("EP BOUND");
 	k_sem_give(&bound_sem);
 }
-static void ep_recv(void *priv)
+static void ep_recv(const void *data, size_t len, void *priv)
 {
-	printk("Msg received");
+	printk("Msg received\r\n");
     
 }
 
@@ -89,9 +89,5 @@
 
 	k_sem_take(&bound_sem, K_FOREVER);
 
-	while(true){
-
-		__WFE();
-	}
 
 }

UART logs from app and net after applying the changes above:

Ref. regarding idle thread Zephyr:  https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/kernel/services/threads/system_threads.html#system-threads 

[dario.sortino]

This is super helpful. Thank you so much. I tried also to have a while loop at the end of my main application that does his stuff (in the real application I read from a bunch of sensors) and it seems that this way I can still receive messages from the other core. And that's great.

Now, if I try to send the rx_payload to the other core the IPC SEND RET MSG returns -2003.

Maybe it is better to send as fast as possible the global rx_payload variable in the while loop at the end of my network core main function, but I wonder why that return is like that.

I'll try to play more with it, in the meanwhile thank you so much for your support.