Good day
I would like to communicate between the M4 and M7 cores on the RT117-EVK.
However, I am running BareMetal OS on the M4 and FreeRTOS on the M7. This operating system selection cannot be changed due to my project's constraints.
I can communicate between the two cores using RPMSG if they are using the same operating system (by creating my own project that mimics either the rmpsg_lite_pingpong_ example or the rpmsg_lite_rtos_pingpong_ example.
But as soon as I change the operating system (and the RPMSG middleware component) from BareMetal to FreeRTOS on the M7, the communication does not work. The master (M7) gets stuck in the second while loop in the image below:
Please let me know if someone knows how to fix this.
@jeremyzhou , thank you for your response.
I used the evkmimxrt1170_rpmsg_lite_pingpong_cm4 and _cm7 main files and rpmsg_config.h files (which are the Baremetal SDK example) as the base for my modifications.
First, let me clarify exactly what my problem is so that you understand the slight modifications I made. The following line, in main_remote.c, executes as expected on the M4 (returns kStatus_MCMGR_Success), but this event is not picked up by the master:
As a result, the main_master.c debug never leaves this while loop:
Based on the evkmimxrt1170_rpmsg_lite_pingpong_rtos_cm4 and _cm7 example files (FreeRTOS SDK example), it seems that FreeRTOS uses RPMSG's nameservice component instead of the above event trigger. Based on this assumption, I copied the code to integrate this from the SDK example into my main_master.c:
and main_remote.c:
I had to modify these function calls slightly - I included the context variables as the last argument for the calls, because the rpmsg_config.h files define RL_USE_STAT_API as 1 (to stay in line with the Baremetal SDK example). However, I don't think this matters, because these are output variables for the functions, I think. Anyway, this has the same result as the aforementioned event, as the main_master.c debug never leaves the while loop (remote_addr is not changed).
I think the best way to replicate what I'm trying to do is to try to use the evkmimxrt1170_rpmsg_lite_pingpong_cm7 example project (converted to FreeRTOS) to control with the evkmimxrt1170_rpmsg_lite_pingpong_cm4 (Baremetal) example project. Another option is to use evkmimxrt1170_rpmsg_lite_pingpong_rtos_cm7 as the master project and adjust it to control evkmimxrt1170_rpmsg_lite_pingpong_cm4 - I have tried this too. As explained above, my modifications have had no effect, so I don't mind leaving them out.
My colleague found the problem. The FreeRTOS master project's code must be placed in a task, and started by calling 'vTaskStartScheduler()'. Previously, my code was running directly in main().
If a task is used, then the two cores communicate via RPMSG as one would expect.
However, I'm not going to close this thread yet, as I would like an explanation for why this is the case? As far as I understand from the FreeRTOS reference manual, the code in main() is run just like the code in a task, before any tasks are started by the scheduler:
Clearly, vTaskStartScheduler() is doing something in the background that I am not aware of.
@jeremyzhou are you aware of why this would be the case?
