R-Car S4 Development Board/Spider
This solution provides a complete development environment with hardware and software for automotive gateway applications to support the new E/E architecture.
Learn about the new multi-core synchronous debugging support in the e2 studio integrated environment for R-Car S4. In-vehicle SoC devices contain multiple CPUs and IPs, and the software shares those 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.
Software title
|
Software type
|
Company
|
---|---|---|
e² studio for R-Car Integrated Software Development Environment. Innovative and Open Development Environment in order to ease SW Development for Computer Vision and Deep Learning Algorithms.
|
IDE and Coding Tool | Renesas |
E2 emulator [RTE0T00020KCE00000R] On-chip debugging emulator. Also available as a flash memory programmer. [Support MCU/MPU: RA, RE, RH850, R-Car D1, RL78, RX, RISC-V MCU]
|
Emulator | Renesas |
IE850A Emulator System for RH850. This product supports external tracing (Aurora tracing) .
|
Emulator | Renesas |
RoX Software Development Kit The RoX SDK is an easy-to-start & easy-to-use development framework for the R-Car SoCs.
|
Software Package | Renesas |
4 items
|
This solution provides a complete development environment with hardware and software for automotive gateway applications to support the new E/E architecture.
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.
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.