Some question about RPMSG in STM32MP1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-16 6:05 AM
​1. When I create an openamp-based virtual_huart0 on the M4 side for exchanging information,some code is as follows:
if (VIRT_UART_Init(&huart1) != VIRT_UART_OK)
{
printf("VIRT_UART_Init UART1 failed.\r\n");
Error_Handler();
}
VIRT_UART_StatusTypeDef VIRT_UART_Init(VIRT_UART_HandleTypeDef *huart)
{
int status;
/* Create a endpoint for rmpsg communication */
status = OPENAMP_create_endpoint(&huart->ept, RPMSG_SERVICE_NAME, RPMSG_ADDR_ANY,
VIRT_UART_read_cb, NULL);
if(status < 0) {
return VIRT_UART_ERROR;
}
return VIRT_UART_OK;
}
and this will create the /dev/ttyrpmsg0 device on the Linux side.To exchange data, I directly use OpenAMP library functions to create nodes,and In Linux, the driver rpmsg client sample will be loaded.some code as follow:
#define RPMSG_SERVICE_NAME "rpmsg-client-sample"
OPENAMP_create_endpoint(&remsgr_ept,RPMSG_SERVICE_NAME,RPMSG_ADDR_ANY,rx_callback,NULL);
Now the problem is: when I first use the driver rpmsg client sample to exchange data, then use the virtual created above_ When huart0 exchanges control information, the data exchange will stop,it doesn't work , and the exchange control information can be exchanged correctly.And there are dmesg information in linux:
Could you give me some suggestions? Thank you very much!
Solved! Go to Solution.
- Labels:
-
STM32MP15 Lines
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-17 10:44 AM
Hello @Mchen.3​
If i well understood you have 2 RPMsg channels:
The first channel created is the "rpmsg-client-sample" channel A7,Linux endpoint address 0x400 M4,stm32cube endpoint address 0x0
The second channel created is the "rpmsg-tty-channel" channel A7,Linux endpoint address 0x401 M4,stm32cube endpoint address 0x1
The issue is probably linked to a race condition due to the management of some context with multi the IPCC interruptions or multi rpmsg callback calls.
- each messgae send from Linux generates an IPCC interruption.
- if there are several rpmsg in the pipe,the OpenAMP library treats all the messages before returning in the main program .
The scenario could be:
- you receive a notification of a new message ( From 0x0 to 0x400) => entrer in the IPCC interruption ( that set a flag?)
- go back from the interruption in the normal context which detects that a new message is received and call OPENAMP_check_for_message.
- the OpenAMP lib gets the rpmsg and call the rx_callback associated to the "rpmsg-client-sample" channel
- while you are treating the message a new IPCC interrupt occurs because you receive a message from /dev/ttyrpmsg0
at this time 2 options:
- A context variable is overwriten in the interruption leading in the non treatment of the first message to answer.
- or leave IPCC interrupt, go back in your rx_callback function, then go back in OpenAMP lib that detects a second message and call VIRT_UART_read_cb. A context variable set in rx_callback function is overwritten by the VIRT_UART_read_cb function.
Don't hesitate to use the remote proc traces (cat /sys/kernel/debug/remoteproc/remoteproc0/trace0) or the stm32cubeIDE debuger to help you to understand the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-17 10:44 AM
Hello @Mchen.3​
If i well understood you have 2 RPMsg channels:
The first channel created is the "rpmsg-client-sample" channel A7,Linux endpoint address 0x400 M4,stm32cube endpoint address 0x0
The second channel created is the "rpmsg-tty-channel" channel A7,Linux endpoint address 0x401 M4,stm32cube endpoint address 0x1
The issue is probably linked to a race condition due to the management of some context with multi the IPCC interruptions or multi rpmsg callback calls.
- each messgae send from Linux generates an IPCC interruption.
- if there are several rpmsg in the pipe,the OpenAMP library treats all the messages before returning in the main program .
The scenario could be:
- you receive a notification of a new message ( From 0x0 to 0x400) => entrer in the IPCC interruption ( that set a flag?)
- go back from the interruption in the normal context which detects that a new message is received and call OPENAMP_check_for_message.
- the OpenAMP lib gets the rpmsg and call the rx_callback associated to the "rpmsg-client-sample" channel
- while you are treating the message a new IPCC interrupt occurs because you receive a message from /dev/ttyrpmsg0
at this time 2 options:
- A context variable is overwriten in the interruption leading in the non treatment of the first message to answer.
- or leave IPCC interrupt, go back in your rx_callback function, then go back in OpenAMP lib that detects a second message and call VIRT_UART_read_cb. A context variable set in rx_callback function is overwritten by the VIRT_UART_read_cb function.
Don't hesitate to use the remote proc traces (cat /sys/kernel/debug/remoteproc/remoteproc0/trace0) or the stm32cubeIDE debuger to help you to understand the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-18 12:15 AM
Ok,thank you very much for your answer! I will check the problem according to your idea.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-18 9:21 AM
In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question.
See also 'Best Answers'
