TDA4VM: IPC shared memory communication, data inconsistency problem

Hi，

    Please help solve this problem, thank you!

    Regards，

    Kong

Hi ,

May i know which SDK version you are using ? While IPC driver file are you using ?

Thanks

Tarun Mukesh

SDK_0806

Hello , 

Tarun Mukesh Puvvada said:

While IPC driver file are you using ?

May i know which driver you are using ? which HLOS is running on A72?

PDK IPC has been tested with A72 linux.

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/07_02_00_06/exports/docs/pdk_jacinto_07_01_05_14/docs/userguide/jacinto/modules/ipc.html

You can run the example of echo test to ensure the communication is working fine at your end.

Regards

Tarun Mukesh

Hi,

    Run Linux on the J721E A72

    Regards,

    Kong

Hello,

Please have a look into IPC echo test example as shared above.

Thanks

Tarun Mukesh

Hi，

    We wrote it according to the test cases you gave us, but it didn't help us with the problem we encountered. Hope you can come up with another useful solution. Thank you!

    Regards，

    Kong

Hello,

With the only snippets you shared it is difficult to understand where the issue might be in your application .I can only see RPmessage send and Recv API's.

Are you using same endpoint while you are facing this issue or have you opened multi channel endpoints?

Regards

Tarun Mukesh

Hi，

    Sure am. So, do you have a better solution?

    Regards，

    Kong

Hi，

    new_index cannot guarantee the success of each write, resulting in incorrect data read by the peer end.

     Regards,

     Kong

Hello ,

In IPC we don't have mechanism to verify the bits sent and received are same between transmitter and receiver.

The data whatever is sent will be written into the respective VRING shared memory and read by the other core.

Put a break point before sending the message and verify you are sending the same data as expected or not.

And if we don't receive from another core after certain limit the data might get lost.

Tarun Mukesh Puvvada said:

You can run the example of echo test to ensure the communication is working fine at your end.

As i said earlier the communication between MCU 1_0 and A72 has been tested at our end and don't have any issue with driver files and have an example application verifying the same.

You are using MCU1_0 and Sci_server task will be running on the MCU1_0 core along with the IPC task which has higher task priority .

I might not be very helpful unless i see the how it is implemented on your application.

KONG XIANGXU said:

We wrote it according to the test cases you gave us, but it didn't help us with the problem we encountered.

May i know what changes have you done it in your source code based on example provided ?

Regards

Tarun Mukesh

The VRING memory which you are using has to be uncacheble and has to not be accessed by other data rather than these 2 cores.

Regards

Tarun Mukesh

Hi，

     Thank you very much for your reply. The ddr shared memory we use to pass data (data larger than 512 bytes) is not a VRING buffer.

      Regards，

      Kong

Hello,

Large Application Shared Memory buffers are expected to be Cached and Appropriate Cache flush/invalidate functions need to be invoked depending on the direction of buffer exchange on both sender and receiver. 

you would use a Shared Memory Allocator to allocate your memory ((or statically reserved carveout) and use the pointer address within a regular RPMessage message.

The VRING buffers are internal to the IPC transport, so application won't be dealing with vring pointers directly. The only time the application is aware is when it has to supply the memory region during the IPC initialization step.

The IPC transport is agnostic of the payload message data structure, so it is all up to the peer communicating entities w.r.t the data structure and at what offset it would pass a pointer to the other side. 

Thanks

Tarun Mukesh