How to resolve hardware resource conflict in Multi-core embedded system?

Thread Starter


Joined Jan 4, 2017
Our application is Advanced Drive Assist Systems(ADAS). Our Electronic Control Unit(ECU) contains Two Renesas RH850 / U2A16 Microcontrollers. Each microcontroller has Four cores. Our Embedded Software Design is based on ETAS Autosar version 4.x RTOS.

Microcontroller A has Four cores. core0, core1, core2, core3. Microcontroller A has Error Control Module (ECM). The problem is that core1, core2, and core3 are all trying to write to ECM registers at the same time. There is a resource conflict where each core is trying to unlock and relock the ECM registers - effectively, this results in the ECM being locked when one or more of the cores are trying to write to an ECM register.

Do we need to add semaphore / OS Resource protection to the ECM functionality such that only one core can modify ECM registers at a time?
What core synchronization services does the ECM have? How will cores share mutually exclusive peripherals? Can this synchronization achieved using a semaphore? Are there any semaphore objects and semaphore services provided to ensure mutually exclusive data access?

Is there inter-core communication that involves sharing of data among cores through sharing of memory space? Is it possible to use message queue object for inter-core communication through which cores send or receive messages placed in a shared memory? Are there any services provided by RTOS that cores can use to send messages to and receive messages from queue? And somehow use these messages to achieve mutually exclusion access to ECM.

In our os configuration file, there is a macro OS_NUM_RESOURCES ( 8U ). The eight resources that are declared are: core0, core1, core2, core3, core0_scheduler, core1_scheduler, core2_scheduler, and core3_scheduler. Can ECM resource be defined as well? Will RTOS manage this hardware resource?

How many of following options will solve this problem?

1. This rtos has 'GetSpinlock' API. GetSpinLock is used to give one core exclusive access to shared resource - typically writeable data. Only one core is able to occupy a specific spinlock at a time. Syntax of this API is 'GetSpinlock ( SpinlockIdType SpinlockId )'. Does this rtos have knowledge of ECM resource? Can ECM be defined as a shared resource? If core 1 occupies spinlock, will rtos prevent other cores from accessing ECM registers?

2. This rtos has APIs such as 'ModifyPeripheral32'. Modifies the 32-bit value at Address by ANDing it with the Clearmask and ORing it with the Setmask. The syntax of this API is: StatusType ModifyPeripheral32 ( AreaIdType Area, unint32 * Address, unit32 Clearmask, uint32 Setmask )
Description of this API: Reads a 32 bit value from the specified address, then does a bitwise AND with the Clearmask and a bitwise OR with the Setmask, before writing the value back.
Typically used to allow code in untrusted OS Applications to modify data from areas of memory that would otherwise be inaccessible because of memory protection settings. The read is done
from a trusted context. Peripheral Areas must be declared in the configuration. Their legal address range must be specified, and also the OS-Application that can access them.
All 32 bits of the modified value must be within the configured address range.
The OS does not prevent two different cores from accessing peripherals at the same time.

What does the last sentence mean? If Three cores use this API simultaneously, there will be ECM resource conflict issue?

3. Is it possible to synchronize cores using event objects? For example, core 2 and core 3 wait for core 1 to set a event?


Joined Jun 4, 2013
This is a complicated question, and unless someone here has used the specific RTOS you're using, you likely won't get much help. My first thought to your questions is that these are great questions for your RTOS vendor. They will surely have the expertise you need. My second thought is that you seem to have created a strange setup where four cores all control the ECM. How do you know they all are writing the right information? Are they all writing the same information, or different. If different, can the ECM keep up with the changes? My third thought is that you probably need to take a look at your overall software architecture, and figure out how to avoid resource collisions, especially in a real time system. Real time programming is not the same as regular programming, and requires special attention to several issues unique to real time systems.
Last edited: