We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Under Cortex-R5, the addresses for cache maintenance are not restricted by the MPU. For example, performing cache cleaning or invalidation operations on an address space without access permission will not cause any exceptions. For example, there are two contexts here called TaskA and TaskB, and during the task switching process, the OS is responsible for maintaining the memory permissions corresponding to each Task context; when TaskA is being executed on the CPU, if the CPU accesses the Memory Space of TaskB, it will be restricted by the MPU; however, at this time, it is allowed to perform a cache invalidation operation on address X belonging to TaskB while executing TaskA. Thus, if the address space corresponding to X is configured as Cacheable + write-back, incorrect cache maintenance behavior will cause Dirty Data in the cache to fail to be correctly written back to memory.
Interesting, I'm afraid I'm not an expert on AutoSar.
SmileSX said:so the conclusion is that in the current Coretex-R5, this scenario (Task In PL1) cannot achieve "protection" of cache maintenance through MPU.
I'd phrase that differently. It's not possible to achieve your goals using your current software model. The processor could give you the isolation you want, if you changed the software model to run Tasks A and B at PL0. There might be plenty of good reasons why you don't want to do that (again, not an AutoSar expert) - but the basic assumption the architecture is that tasks run at PL0 and the management code/OS/RTOS/whatever running at PL1.