Memfault Beyond the Launch

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

Started by learn 4 years ago1 replylatest reply 4 years ago140 views
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?
[ - ]
Reply by rmilneJune 15, 2020

I would direct all your questions to ETAS.  If you are actively using their products then support will be provided.  If you don't have a relationship with ETAS then you shouldn't be using their products.

I haven't used the MCUs that you mention but I would be very surprised if there wasn't a common memory area that spans cores to allow intrinsic test-and-set for synchronization.

Memfault Beyond the Launch