Sample program for communicating between application and net core in NRF5340

[Ajitsj]

Hi,

We are developing a software application for our healthcare project on NRF5340 development kit. It requires an array of data (600 bytes approx) to be shared from application core to net core and vice versa.

Please could someone tell us a sample program (which can be used to share bytes of data) that we can take to communicate between the application and net core?

Also we would use the multicore program which would create a single build hex file called as "merged_domains.hex". Can we directly take this hex file and flash onto the NRF5340 board using the programmer tool?

We also need to know where the separate hex files would be present for each core in the "build" folder?

Thanks and regards

Ajit S J

[Edvin]

Hello,

You can look into the IPC sample found in NCS\nrf\samples\ipc, which is also described here.

What NCS version are you looking into? The reason I ask is that I believe there was an issue with this sample in v2.3.0 of NCS. I can look into it if that is the one you are using.

To flash the samples you can either use VS Code, and hit flash. Otherwise you can use the command "west flash build" where build is the build folder. If you want to see what this command is doing, you can add a -v (verbose) to that command: "west -v flash build", and you can see that it splits up the merged .hex file into two. One for the app core and one for the net core. 

Otherwise, the build\zephyr\merged_domains.hex is the file that you can upload in nRF Connect for Desktop -> Programmer, and it will flash both cores.

On a sidenote: The 600 bytes that you need to transmit from the app core to the net core. Do you intend to send them via BLE? Because if so, I think you are taking one step too far. Building any sample that uses BLE will handle both of the cores for you, and upload whatever is needed to the respective cores.

Best regards,

Edvin

[Ajitsj]

Hi Edvin ,

Thanks for your response.

We have our proprietary protocol which is used to transmit/receive data packets with our patient monitor over radio 2.4GHz frequency. According to this protocol, we would get the data collected in the application core and we would need to send these data packets from application core to the network core to transmit over the radio. So we are not using the BLE tool. 

We are using "v2.3.0" of NCS. 

As part of this exercise we found that there are three ways to send the data between app and net cores.

1) IPC

2) Rpmsg service

3) OpenAMP

Could you please let us know the best way to among these and point to the correct samples which transmit the data between the cores?

Regarding the merged hex file, we would like to know where would the different cores hex files be present in their respective build directories before getting merged. We do not want to split the hex files. 

Thanks and regards,

Ajit S J

[Edvin]

Hello,

Ajitsj said:

The "rpmsg_service" got flashed onto the APP core and the "rpmsg_service/remote" got flashed onto the NET core.

Can you please explain what you mean by this, or how you did that? Screenshot or snippets of commands or something.

Did you check what the log from the net core says?

Best regards,

Edvin

[Joep_K]

I'm having this exact issue also. The endpoint never seems to bind and the application gets stuck here. Using a BL5340 DVK board from Laird. I'm also using SDK V2.3.0 and VS code.

[Joep_K]

Here is the output from the terminals from the app and net core:

[Edvin]

What version of NCS are you using? I am seeing some issues, but not the same as you. 

[Joep_K]

I'm using V2.3.0, same as Ajitsj

[Edvin]

Can you please share how you built and flashed the sample?

According to Ajitsj , he built and flashed two different samples to the different cores, but I am not sure exactly what he did. Perhaps one of you can share what you did.

BR,
Edvin

[Joep_K]

I did the following:

1. Open VS code. Create new application with these settings:

2. Create build configuration with these settings:

3. Let build configuration process complete.

4. Hit "build" in ACTIONS menu.

5. Start "Programmer" V3.0.8 from nrfconnect for desktop.

6. Connect to dev board

7. Add hex file C:\_btTest\rpmsg_service\build\zephyr\zephyr.hex

8. Add hex file C:\_btTest\rpmsg_service\build\rpmsg_service_remote-prefix\src\rpmsg_service_remote-build\zephyr\zephyr.hex

9. The "Programmer" UI now looks like this:

10. Hit "erase and write"

11.  Open two putty terminals to COM9 and COM10 (one for each core)

12. Hit "reset" button (S3) on board after flashing is completed

13. observe the following output in the terminals:

I'm running this example on a BL5340 DVK from Laird (part number: 453-00052-K1).

[Edvin]

I see. I built them separately (rpmsg_service for app core and rpmsg_service\remote for net core), and I see the same as you are seeing. I also see that this is reported as a bug internally. However, since it is in the Zephyr repository I am not sure what the flow will be for this. 

I also see that when I built it for v2.1.2 it works, so this was broken some time after this. 

I am sorry, but I don't have a fix for this right now. But I will ping the internal ticket and try to make them fix this for the next release.

Best regards,

Edvin

[Joep_K]

Hello Edvin,

Thank you for your help. I've changed the SDK over to 2.1.2 and now I'm able to get the example to work. Unfortunately, making the switch means I'll have to make some changes to my main application to make everything work again.

Do you happen to have an ETA on the next release? Or perhaps a work around we can implement temporarily?

[Edvin]

Hello,

I see from the internal ticket that there is a discussion whether or not we will put effort into making a fix "upstream" (meaning in the zephyr repository, which is not something that we can control directly). Please note that there are many samples in the zephyr directory that doesn't run (is not intended to run) on our boards. 

I suggest, if you want a quick fix for this, you should report it as a github issue in Zephyr's github repository, and see if they can investigate the bug, and possibly provide a fix. 

It looks like we will do the same, but chances are higher that a fix will come sooner if it is reported from several holds. 

Best regards,

Edvin