Hello Champs,
Customer is testing ipc communication between m4f and a53-linux. He got the ti-rpmsg-char code from git-clone (link https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/)) and modified ti-rpmsg-char code, recompiled it.
I modified the ti-rpmsg-char code to send out any length of data, as shown in the following figure, data_len is the length of the send data obtained from the ssh command line, whereas the original code only issues "hello there %d"
This code is communicatiing to m4f, the function of the m4f side is what is received and what is returned (one thing he already understands is that the user data cannot be sent more than 496 bytes).
As shown in the following figure, when he sends 256 bytes or less, linux receives the reply from the m4f side in its entirety, starting with ‘s’. End with ‘e’
As shown in the following figure, when he sends more than 256 bytes, the linux side only receives 256 bytes of data, and sending 496 bytes also returns 256 bytes. 300 bytes, which returns 256 bytes,
He printed the message through the m4f serial DebugP_log function and saw that m4f actually received all the data, and when it was sent, it was passed in to the RPMessage_send function as long as it was received.
However, if it does not come out, it is truncated beyond 256 bytes.
The following figure shows the configuration of the m4f-side vring, the number of vringbufs is 256, each vringbuf is 512 bytes long (512 bytes already here, why is the 256 byte truncation problem described above?)
Below is the part of the code where the m4f side is being received
#define IPC_RPMESSAGE_MAX_MSG_SIZE (512u)
char recvMsg[IPC_RPMESSAGE_MAX_MSG_SIZE+1]; /* +1 for NULL char in worst case */
/* wait for messages forever in a loop */
while(1) {
/* set 'recvMsgSize' to size of recv buffer,
* after return `recvMsgSize` contains actual size of valid data in recv buffer
*/
//DebugP_log("runing task_id=%d localEndPoint=%d rec_cnt=%d\r\n", inputArgs->task_id, localEndPoint, rec_cnt);
recvMsgSize = IPC_RPMESSAGE_MAX_MSG_SIZE;
status = RPMessage_recv(pRpmsgObj,
recvMsg, &recvMsgSize,
&remoteCoreId, &remoteCoreEndPt,
0);
if(status==SystemP_SUCCESS)
{
/* echo the same message string as reply */
#if 1 /* not logging this so that this does not add to the latency of message exchange */
recvMsg[recvMsgSize] = 0; /* add a NULL char at the end of message */
//DebugP_log("recvMsg:%s\r\n", recvMsg);
#endif
/* send ack to sender CPU at the sender end point */
status = RPMessage_send(
recvMsg, recvMsgSize,
remoteCoreId, remoteCoreEndPt,
RPMessage_getLocalEndPt(pRpmsgObj),
5);
//DebugP_log("Rec Size=%d Cnt=%d ",recvMsgSize, rec_cnt);
rec_cnt ++;
if(status==SystemP_SUCCESS)
{
//DebugP_log("send ok %d\r\n", send_cnt);
send_cnt++;
}
else
{
DebugP_log("send error = %02X\r\n", status);
} //DebugP_assert(status==SystemP_SUCCESS);
}
else
{
vTaskDelay(1);
}
}
Question 1: What is the problem and how to fix it?
Question 2: What are the two parameters of IPC_RPESSAGE_NUM_VRING_BUF and IPC_RPESSAGE_MAX_VRING_BUF_SIZE that are found in the following figures?
Are there are NUM_VRING cache areas in ipc communication, each of which is VRING_BUF_SIZE, if so, Does linux send NUM_VRING messages in succession, m4f never reads, and once read is started, NUM_VRING messages can be read and removed?
/* Number of a buffers in a VRING, i.e depth of VRING queue */
#define IPC_RPMESSAGE_NUM_VRING_BUF (256U)
/* Max size of a buffer in a VRING */
#define IPC_RPMESSAGE_MAX_VRING_BUF_SIZE (512U)
Thanks
Regards
Shine
