rpmsg-lite master and remote how to ensure link-up successful in our application?

[yzs]

hi,

        In the demo of multicore rpmsg-lite pingpong communication using the SDK for the FRDM-MCXN947 board, I found that after the master core bootstraps the remote core to start, the remote core does rpmsg_lite_remote_init() first, then notifies the master core, and then the remote core waits for connection (rpmsg_lite_wait_for_ link_up()). During this time the master core waits (while()). After the master core is initialized rpmsg_lite_master_init(), the remote core makes the connection and creates the endpoint, then notifies the master that it is ready to send data. In use, I commented out the notification as well as the wait code and found that the master and remote cores can also link-up and communicate, what is the reason for this? Is it because the master system clock is slower than the remote ?
            In addition, I would like to ask, if our MCU does not have such a notification mechanism, how to ensure that the master and slave cores are link-up and can communicate?

Thanks & Regards

yzs

[Celeste_Liu]

Hello @yzs ,

Thanks for your post and sorry for the delay. 

Based on the situation you mentioned, I conducted the following tests. I used the following pair of examples.

The link relationship between core0 and core1 can be seen in the properties of rpmsg_lite_pingpong_cm33_core0.

Then, as you suggested, I commented out the relevant code for notification and waiting in main_remote.c of rpmsg_lite_pingpong_cm33_core1.

      /* Signal the other core we are ready by triggering the event and passing the APP_RPMSG_READY_EVENT_DATA */
-101 (void)MCMGR_TriggerEvent(kMCMGR_RemoteApplicationEvent, APP_RPMSG_READY_EVENT_DATA);
+102 //(void)MCMGR_TriggerEvent(kMCMGR_RemoteApplicationEvent, APP_RPMSG_READY_EVENT_DATA);

-107 rpmsg_lite_wait_for_link_up(my_rpmsg, RL_BLOCK);
+108 //rpmsg_lite_wait_for_link_up(my_rpmsg, RL_BLOCK);

After that, I recompiled rpmsg_lite_pingpong_cm33_core1, then flashed the compiled bin file again and retested it. After several tests, it was found that the master and remote cores were unable to communicate.

Therefore, I suspect that there might be an operational issue on your end. Did you recompile after commenting out the code? Or are there any differences between your operations and mine? Please let me know so that I can continue the investigation.

I didn't see any indication anywhere that the clocks of the master core and the remote core are different.

You can also use mailbox to achieve multi-core communication. There are demo like this in the SDK. You can go and have a look.

Hope it can help you.

------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you!
------------------------------------------------------------------------------------------

BRs,

Celeste

[yzs]

hi, @Celeste_Liu 

 Thanks. I confirmed that my modification communicates properly, but I didn't comment out this code rpmsg_lite_wait_for_link_up(my_rpmsg, RL_BLOCK) and I commented out both the master side as well as the remote side (void)MCMGR_TriggerEvent(kMCMGR_ RemoteApplicationEvent, APP_RPMSG_READY_EVENT_DATA) on both the master and remote side. It may be the difference here that is causing our test results to be different, as can be seen in the attached image.

But I found that after commenting out rpmsg_lite_wait_for_link_up(my_rpmsg, RL_BLOCK) it still communicates fine!

So I would like to make sure, how to ensure that core0 and core1 are  and communicating if there is no such notification mechanism in our platform and core0 runs master_main() first?

BR

yzs

[Celeste_Liu · Accepted solution]

Hello,

Thank you for your detailed explanation. As you mentioned, I have tried it and indeed reproduced the situation you described. Regarding how to ensure the communication between the two cores, you can use shared memory combined with flag bits or ISR.

I'll share some links that might be useful to you:

mcuxsdk-middleware-multicore/mcmgr/doc/MCMgrDataExchangeDiagram.png at main · nxp-mcuxpresso/mcuxsdk...

RPMsg-Lite User's Guide: RPMsg Component

BRs,

Celeste