Device Tree overlay ipc icmsg sample

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Tue, 21 Feb 2023 09:51:53 GMT

I suggest you use the Zephyr logger module in deferred mode (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/services/logging/index.html). This will cause the log messages to be processed in a separate low priority logging thread, so it won't block your other tasks.

You may also consider using the RTT backend instead of UART as it is considerably faster.

To use prinkt with the logger, you can enable CONFIG_LOG_PRINTK=y.

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Thu, 16 Feb 2023 11:30:27 GMT

I made some tests and I found out that by removing EVERY printing involved in real-time, I can send every message received via ESB to the application core, elaborate it and print using printk in the debug USB of the dk only the first byte of the payload (that for me represents the node ID).

Curious enough, I found out that I can also do the same processing in the work queue I set up in the network core, even though I cannot print the whole message received, but checking the first byte is fine.

I am confidant enough to say that printk is too slow for the smooth execution of the whole application. I'll try to switch to the nRF USB using CDC ACM in the application core. Any reference for that?

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Wed, 15 Feb 2023 15:36:42 GMT

I tried to set a work queue like in the example you mentioned. It seems to be an improvement. I'm still experiencing weird stuff, such that not every rx_payload is processed by the work queue: notice that I print the ID in the ESB RX event, and the IPC SEND RET MSG in the work queue after having sent the data.

One other thing I'm noticing though, is that in my application core I have in the main a while loop as simple as this

while(true){

	printk("Do stuff\n");
	k_msleep(25);
}

and the following is happening:

1) I remove completely the k_msleep: the ipc receiving interrupt is not executed.

2) I set k_msleep to 25. I expect to see prints from my ipc receiving interrupt interleaved more or less regularly (we receive from ESB every 800 us) by the "Do stuff" print. This doesn't happen, as sometimes the "Do stuff" is not printing for a long time

3) I remove the whole while loop: everything seems to work as intended.

So, in my final application, I will do for real some stuff in the while(true) of the main in the application core: why I do observe such behavior in case 2? It's a matter of lag due to the working queue? It seems very strange to me since this would mean that we don't have the same computing power that we have if we run this whole example in the nRF52840 as we currently do. The whole point for me to send to the other core, apart from being able to be as flexible as I want, is because I cannot run some simple operations on data in the network core.

Also, but that would be very extreme and I would be very concerned of that, it may be that is the usage of print that is eff-ing me up instead of a more elegant usb_cdc (or whatever) peripheral?

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Wed, 15 Feb 2023 13:39:58 GMT

I am not exactly sure what the exact root cause is, but I suspect the problem is caused by the fact that you are calling the send function from an interrupt context (SWI0_IRQ from esb). A solution in that case can be to offload the sending task to the system workqueue like how it is done here: https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/dm/rpc/client/dm_rpc_client.c#L136 where data_handler() is a workqueue item:

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Wed, 15 Feb 2023 11:35:57 GMT

Yes Vidar, it was clear enough that the problem was the __WFE().

I have no idea what the ERR_PARAM can be since I only observe it if I try to send messages when the ESB_EVENT_RX_RECEIVED triggers. You can replicate the problem yourself if you send in the ESB_EVENT_TX_SUCCESS case of the ESB event handler (make variable "a" global first). I can only suspect that there is a problem with the endpoint, what do you think?

If I send the same structure in the while loop inside the main, I can correctly observe my data structure in the application core.

The problem is that this way, I don't know why, I can only send data from one (occasionally 2) node out of 3 nodes of my network: it seems that the sending operation in the while is done "slower" with respect the ESB_RX callback.

In the application core, everything works fine as long as I use a small k_msleep (I'm using 5 msec): If I keep the while doing its stuff without sleeping (e.g: printing something), I no longer receive any message.

I think that I'm stuck understanding priorities in ISRs and I just need to figure when operations are done with respect to others.

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Wed, 15 Feb 2023 08:36:47 GMT

Good to hear! I was a bit unclear earlier; I don't think the problem is the loop itself, but the __WFE() instruction (you are not supposed use it directly in Zephyr). Typically, you will use k_sleep() when you want to pause a thread to enter sleep.

[quote user="dario.sortino"]Now, if I try to send the rx_payload to the other core the IPC SEND RET MSG returns -2003.[/quote]

-2003 corresponds to RPMSG_ERR_PARAM indicating that the one of the parameters passed to the function call were invalid. Are you able to spot any differences in the parameters you have compared to the ipc service sample?

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Tue, 14 Feb 2023 14:34:20 GMT

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.

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Tue, 14 Feb 2023 14:03:39 GMT

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.

devzone.nordicsemi.com/.../4857.diff.diff

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

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Tue, 14 Feb 2023 11:24:07 GMT

devzone.nordicsemi.com/.../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.

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Tue, 14 Feb 2023 11:09:48 GMT

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

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Tue, 14 Feb 2023 11:08:29 GMT

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

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Tue, 14 Feb 2023 11:00:17 GMT

Yes, I think it would help if I could debug your application on my end. Do you want me to turn this into a private ticket before you upload it?

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Mon, 13 Feb 2023 13:44:12 GMT

Hey Vidar, thanks for your reply. Unfortunately, I couldn't figure out what was wrong with my application. I switched from IPCMSG to RPMSG, such that I'll follow as much as possible the default configuration of the ipc_sample, without the need to create an overlay, but I cannot see any message that I try to send from one core to another.

I was drastically thinking of using the ESB stack in the application core, but I soon realized that every radio operation is strictly managed by the network core. So the only way for me to proceed is to send data between cores.

Maybe it's easier if you have a look at my whole application, what do you think? It really is nothing so much complicated, but I can't figure out what's wrong.

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Wed, 08 Feb 2023 13:39:44 GMT

Hello,

The default ipc0 configuration is defined here for the app core: https://github.com/nrfconnect/sdk-zephyr/blob/main/dts/arm/nordic/nrf5340_cpuapp_ipc.dtsi and here for the netcore: https://github.com/nrfconnect/sdk-zephyr/blob/c4b528788ce7927f0f8a7da487a8f5c8bbe5643e/dts/arm/nordic/nrf5340_cpunet.dtsi#L312. And same for the shared RAM region: https://github.com/nrfconnect/sdk-zephyr/blob/main/boards/arm/nrf5340dk_nrf5340/nrf5340_shared_sram_planning_conf.dts. These configurations can all be overriden with a DT overlay.

Are you also building the ESB without the overlay? Either way, I suggest you compare the generated zephyr.dts for both builds to verify that they use the same shared RAM area.

RE: Device Tree overlay ipc icmsg sample

dario.sortino — Mon, 06 Feb 2023 15:35:53 GMT

Hello, I've created overlays as in the sample.

I think that you are right in saying that the pristine build broke suddenly my application. If I remove the overlay (by not setting it in the CMake) that defines the ipc0, the initialization works fine, and the BUS FAULS won't appear.

So, where do I see how the ipc0 device is defined? I'm working with an nRF5340 DK. I don't get why the ipc_sample works perfectly on the DK, and my application that is replicating that structure fails: even if everything is initialized and works fine, in the end I cannot send messages from the network core to the application (ipc_service_send return code -2003).

My application consists in listening to incoming ESB messages in the network core, then I'd like to send the payload to the application core.

RE: Device Tree overlay ipc icmsg sample

Vidar Berg — Mon, 06 Feb 2023 15:04:23 GMT

Hello,

Assuming you have created a Devicetree overlay for this, do you get the same error if you remove the overlay from the project? When adding a new device tree overlay, it will only be picked up by the build system after you do a clean/pristine build, so I wonder if that could explain why it suddenly started failing.

Also, does your existing application use IPC for other things like communication with the Bluetooth controller.

Thanks,

Vidar