Handling Exclusive accesses in multi-core Cortex-M7 systems
Information in this article applies to:
How are semaphore instructions, Load exclusive and Store exclusive, handled in multi-core Cortex-M7 systems?
Intended audience: This knowledge article is of interest to chip designers and system programmers of multi-core chips containing Cortex-M7 processors and which need to support exclusive accesses for semaphores or mutexes.
The Cortex-M7 processor is a high performance embedded processor with optional instruction and data caches. The processor design does not provide cache coherency, which is deemed too expensive for small microcontroller systems. Therefore, system designers and RTOS software developers need to take additional measures to allow semaphore operations to work correctly in multi-processor designs.
The Cortex-M7 processor supports optional features including a Memory Protection Unit (MPU), Tightly Coupled Memories (TCMs), and an optional internal data cache. The optional data cahe has the following features:
No cache coherency support.
Address space that is declared as shareable in the MPU settings is not cached.
Exclusive accesses to non-shared cacheable address ranges do not trigger bus level exclusive signaling.
By default, the CODE, SRAM, and RAM regions of the Armv7-M system address map are not shareable and are cacheable. However, software can override these memory attributes using the MPU.
TCM address ranges do not support the required signaling for shared exclusive operations.
While data coherency in a multi-core Cortex-M7 system can be managed by software (using cache clean and invalidate functions), semaphore operations require additional attention.
If an RTOS must work across multiple cores in a multi-core Cortex-M7 design, and uses exclusive accesses for semaphores, the semaphore variables must be placed in address locations declared as shared, or in non-cacheable locations, to ensure that both the data value and the exclusive property are propagated. Otherwise the following problems occur:
The software running on different cores might not have same view of the semaphore data.
Even if the data coherency is maintained when accessed from different cores (e.g. by using cache clean and invalidate operations), exclusive access conflicts can not be detected because bus signals for exclusive accesses are not propagated for Non-shared cacheable regions.
Software developers should place semaphore data in a memory region which is declared as shareable in the MPU.
Since shareable data is not cached, there could be a performance impact if the memory is slow. This is unavoidable.
If the Cortex-M7 device does not have an MPU, an alternative solution is to put semaphore data into regions that have a Device memory type. While the Armv7-M architecture does not specify support for exclusive accesses in Device regions, exclusives are supported in Device regions on the Cortex-M7 processor.
In both cases:
A system level exclusive access monitor is required in front of the memory in which the semaphores are located, to detect exclusive access conflicts between the different processors.
Potentially, the RTOS source code might need to be updated to separate the semaphore addresses from other data. In many case the RTOS source code mixes all data together and expects the RTOS to be compiled and linked as a single block. Such an arrangement might not allow the tool chain to separately place semaphore data in a shareable region unless the source code is modified.
Support of exclusive accesses in Device regions becomes mandatory in the Armv8-M version of the architecture.