How do you coordinate each other?

With the continuous development of automotive intelligence, the automotive electronics industry has an increasingly large market. As the main control device of NXP in automotive electronics, MPC series high performance and high security MCU is gradually improving its position and playing a more significant role. This article takes the practical application of MPC5746R as an example to explain how the two cores can coordinate with each other and jointly exert greater performance.

The MPC5746R uses a dual CPU core mechanism with two independently programmable e200z425-based cores 0 and 1, each with a maximum frequency of up to 200M. There is also a security kernel based on e200z424 for running in sync with kernel 0 to ensure the reliability of the program while it is running.

The two cores of the MPC5746R share on-chip peripherals and memory units. At the same time, the interrupt controller can provide separate core control units for the two cores, so that the interrupt request can be handed over to different core processing according to user settings.

Users can write separate programs for the two cores, and it looks like one system is running two threads. This is also true. The two cores execute the programs written by the users for each other in parallel at 200M, handling various complex tasks. But sometimes there are some problems that cause unpleasant things to happen.

Here are a few examples:

1)      At some point, kernel 1 writes data to a register to perform function 1, but unfortunately kernel 0 also needs to write data to this register to perform function 0. Simultaneous write conflicts may cause both function 0 and function 1 to fail to execute properly, and should be avoided.

2)      Since there is only one peripheral resource, assuming that the user sets kernel 1 to initialize the system and resources, kernel 0 needs to perform related function operations after the initialization is completed, then how kernel 0 knows that the initialization has been completed within the first time.

3)      Kernel 1 and Kernel 0 work together to handle complex algorithms. When Kernel 0 has processed a portion of the algorithm, it wants to pass the processing result to Core 1, and how to communicate with each other's independent dual cores. How to save communication time.

In fact, when the chip was designed, these problems have already been considered, and corresponding functions have been made to ensure the coordinated operation between the dual cores. Based on the above examples, we need to understand an important knowledge point called semaphore, which is a mechanism for resource protection and synchronization between processes.

The MPC5746R provides 16 channels of hardware semaphore for the user to use. The user can write the number corresponding to the processor to lock a certain semaphore and only the processor that locks the signal can unlock the signal. This provides a hardware foundation for resource access protection and synchronization between processors.

We solve the problems faced by the three examples of appeals in a concrete way:

1)      Before the kernel writes a register, it first detects whether the semaphore is locked. If it is locked, wait for the signal to unlock and then operate. If there is no lock, lock a semaphore first, and then release the semaphore after the operation is completed, so that An access violation for a shared resource occurs.

2)      Kernel 0 needs to wait for kernel 1 initialization to complete before it can perform functional operations, that is, synchronization with kernel 1. The amount of semaphore can be unlocked at the beginning of the kernel 1 program, and after the initialization is completed, the semaphore is unlocked. Kernel 0 waits for the semaphore to be unlocked at the beginning of the program. Once unlocked, it indicates that the initialization is complete, that is, the synchronization operation is completed, which solves the second problem of appeal.

3)      One of the most important issues when two cores are communicating is how the receiver is ready to receive data without consuming too much CPU resources. In the MPC5746R, it can be solved by a soft interrupt. When kernel 1 needs to send data to kernel 0, first configure the priority of the software interrupt, and then set the interrupt request to kernel 0. After the data is written, an interrupt is triggered and an interrupt request is sent to core 0. As long as the kernel 0 writes the corresponding interrupt service function, it can complete the communication between the cores by interrupting the reception of data without consuming more CPU resources.

It should be noted that the MPC5746R does not create a separate space for access to communication data between independent dual cores. However, in practical applications, a feasible method is to flexibly use unused buffer units in each communication module. For example, in the CAN module, there are up to 96 data buffer structures, and CAN communication may not always be used. We can use several data buffer units as the channels for data transmission between cores according to actual needs. The kernel that needs to send data writes the data to the specified data buffer structure and then triggers a software interrupt. The receiving side reads the data from the data buffer structure in the interrupt service function. Some flag bits can be set in the buffer structure to determine whether the reading and writing is successful.

The above are some specific examples of resource protection, synchronization and communication between dual cores. Of course, the method is not unique. I hope that readers can use the same process in a flexible manner and finally achieve the goal of “dual-core crossfire and coordinated operations”.