Closed hwwei521 closed 1 year ago
Hello @hwwei521 are you using FreeRTOS on the cm4 core app (rpmsg_lite remote)? rpmsg_lite_wait_for_link_up() impl. depends on the environment, for freertos it is implemented as env_wait_for_link_up() in rpmsg_env_freertos.c. If the link_state is not set, env_wait_for_link_up waits until the dedicated event bit is set which happens once the env_tx_callback is issued (triggered from the master side, i.e. the Linux app in this case). Are you trying the setup described in #33 ?
Hello MichalPrincNXP Thanks for your replay, yesterday I habe tryed to set the linkup state, env_wait_for_link_up need the master send a mailbox interrupt to triger the tx env_isr , in the software process, it will call virtiqueue_notification (vq->callback_fc(vq)), then will call the tx_cb when create virtqueue registered. The https://github.com/nxp-mcuxpresso/rpmsg-lite/issues/33 i have tried, but there is something wrong, it doesn't work.
Hello @hwwei521 , you wrote "mailbox interrupt" ... isn't it the "MessagingUnit interrupt" on evkmimx8mq? (asking just to understand your case). Anyway, is your question answered or do you still see any bug in the code?
Hi @hwwei521 , can we close this issue?
In boards/evkmimx8mq/multicore_examples/rpmsg_lite_pingpong_rtos/linux_remote/main_remote.c file, In my view, after call rpmsg_lite_remote_init, the local direct to wait link_up will have something not good, who will set rpmsg_lite_dev->link_state to 1 let the task run continue, if no one set rpmsg_lite_dev->link_state to 1, the task will block here. ` static void app_task(void *param) { volatile uint32_t remote_addr; volatile rpmsg_ns_handle ns_handle;
ifdef MCMGR_USED
else
endif / MCMGR_USED /
`