Corrupt messages delivered at times from Linux to BM with OpenAmp SDK2016.3 on Zynq7000
I have integrated OpenAmp messaging between Linux on CPU0 and BareMetal on CPU1 on proprietary hardware.
Linux is a master while BM is a slave responding only when requested. Linux app is a multithreading and it could write simultaneously number of requests not necessarily waiting for confirmation before next request is generated. BM will respond to each of requests, but not necessarily in same order as they arrived. Since each request and response is keyed in with unique id this is not a problem.
The system most of the time works fine. But In 12 hours trials I'm getting about 30 (out of thousands) messages received on BM that instead of 40 bytes as expected will contain what looks like message that was a BM response provided earlier. Now, if I impose locking mechanism on the Linux side to serialize each request with response assuring in effect that only one OpenAmp message is outstanding at any given time system performs without any error.
I have checked ug1186/2016.3 and notice Figure 1-1 is illustrating scheme with each message followed with the response in 1-1 relationship. I assume this is an illustration not a system requirement.
Questions: 1) Is OpenAmp capable of handling asynchronous messaging scheme or there are limitations when CPU1 can write response back ? 2) Is a newer release of OpenAmp any improvement on 2016.3 in that regards ?