cancel
Showing results for 
Search instead for 
Did you mean: 

Some question about RPMSG in STM32MP1

Mchen.3
Associate

​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:

0693W00000Bb9vxQAB.png 

Could you give me some suggestions? Thank you very much!

1 ACCEPTED SOLUTION

Accepted Solutions
ArnaudP
Senior

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.

View solution in original post

3 REPLIES 3
ArnaudP
Senior

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.

Mchen.3
Associate

Ok,thank you very much for your answer! I will check the problem according to your idea.

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'

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.