Learn about the new multi-core synchronous debugging support in the e2 studio integrated environment for R-Car S4. It is equipped with the CPU and IP, and software shares the resources. A lot of effort is required to analyze and solve the problem if a problem occurs in the operation during the software integration stage. To address this issue, Renesas has developed the “Multi-Core Debug and Trace Tool,” a tool that facilitates analysis and identification of the causes of problems resulting from the interaction of multiple hardware resources in R-Car.
Automotive ECUs, especially those such as central ECUs with advanced processing, are equipped with multiple cores which work together in a single SOC. When you combine software running on multiple cores, it can be time-consuming to identify which software is causing the problem.
Examples of the issues when using traditional development tools are described below.
As seen in the figure on the right, it was previously a common practice to stop the operation of the G4MH cores and check the status of registers, memory, and variables using a debugger when something abnormal occurred in Software-A running on the leftmost G4MH core and you wanted to debug it. However, even if the G4MH core is stopped, the other cores would still be running, so if you attempt to see what was happening in Software-B or C when a problem occurs in Software-A, Software-B or C may have progressed further or, in some cases, may not be working at all. It may be that the behavior of Software-A is so strange, due to the fact that it is stopped, that we cannot get to the fundamental problem.
The same is true in the use case where there are multiple devices on the right side, and where even if SoC B is currently stopped to debug Software-B, the neighboring SOC A and MCU continue running. So on the right side, you can have a problem similar to the example of multiple cores in the SOC.
Example: When you want to identify a problem event (CR52 State-1) by referring to the state of the S/W variables and I/O inside the SOC when the problem event occurs.