bug in FreeRTOS_BSP_1.0.1_iMX6SX rpmsg (pingpong demo)

[davidclaessens]

Hello,

There seems to be a bug in FreeRTOS BSP V1.0.1 for the iMX6SX.

When running the rpmsg pingpong demo with V1.0.0 the variable pingpongs from 0 to 199999 (100000 iterations) on the A9.

However, when running the same demo with V1.0.1 the variable goes to 999 and is then reset to 0 and then up to 999 again to be reset for its 100000 iterations.

Using a second application on the A9 the problem seems to be located in the receive where 256 is sent from the A9 but the M4 says its received 0. This second application keeps counting till overflow with V1.0.0.

[Carlos_Musich]

Hi David,

The M4 cache is being configured incorrectly and rpmsg occasionally gets old data. Correct FreeRTOS v1.0.1 as follows and the pingpong demo (etc.) will behave as expected.

--- platform/devices/MCIMX6X/include/MCIMX6X_M4.h.orig 2016-09-21 11:09:21.659568925 -0500
+++ platform/devices/MCIMX6X/include/MCIMX6X_M4.h 2016-09-21 11:22:34.401620557 -0500
@@ -25581,7 +25581,7 @@
 
 /* LMEM - Peripheral instance base addresses */
 /** Peripheral LMEM base address */
-#define LMEM_BASE (0xE0082000u)
+#define LMEM_BASE (0xE0002000u)
 /** Peripheral LMEM base pointer */
 #define LMEM ((LMEM_Type *)LMEM_BASE)
 #define LMEM_BASE_PTR (LMEM)

Regards,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kubiznak_petr]

Hi Carlos,

One year has passed and there is still no official patch available. Is henriroosen‌'s answer correct? The inter-core communication is a critical feature, and I'm not very familiar with the system cache, so I would highly appreciate some official solution.

[hroosen]

Hi Carlos,

You are right that the rpmsg examples broke after M4-caching was enabled, but your proposed fix is not the correct solution: LMEM base is correct to be at (0xE0082000u). And when it is at the correct base, the LMEM initialization at SystemInit() enables caching. When using rpmsg, you have to take care of any caching behavior of the Inter Processor Shared Memory.

if an application requires caching to be switched off, then the proper interface would be the LMEM_DisableSystemCache(). Or instead of switching off the system cache globally, another solution would be to have the rpmsg framework take care of the caching of shared memory (either by using LMEM_FlushSystemCacheLines()/LMEM_InvalidateSystemCacheLines() or using uncached shared memory).

Regards,

Henri

[Carlos_Musich]

Hi David,

thank you for reporting this. I have reproduced this behavior and I find it very strange because the source files of the M4 application are identical in both cases.

I will report this to our development team.

Regards,

Carlos