The Infineon AURIX™ TC3XX family of microcontrollers is a high-performance, multi-core processor platform for automotive electronics and industrial control, with an architecture designed with real-time, functional safety (ISO 26262) and information security in mind. The TriCore™ heterogeneous multi-core architecture combines the features of a RISC (Reduced Instruction Set Computer) and a CISC (Complex Instruction Set Computer), integrating a 32-bit RISC CPU, a DSP unit and dedicated peripheral controllers, with a main frequency of up to 300MHz, and a built-in HSM (Hardware Security Module), which provides significant advantages in terms of ASIL-D functional safety certification and information security protection. The built-in HSM (Hardware Security Module) provides significant advantages in ASIL-D level functional safety certification and information security protection. In terms of storage subsystem design, TC3XX innovatively integrates the Cache mechanism and Data Access Overlay technology, effectively solving the key contradiction between real-time data processing and storage access efficiency in automotive electronic systems.

CACHE OVERVIEW

The cache system of TC3XX is divided into PCache (Instruction Cache) and DCache (Data Cache), and the internal composition of Cache includes Cache controller and two SRAMs (Tag RAM, DATA RAM). The Program Cache (PCACHE) adopts a two-way group-connected cache structure, with two cache lines available in each group, and the size of each cache line is 256 bits. For the typical bus access pattern of automotive electronics, the cache controller uses the Least Recently Used (LRU) algorithm for cache replacement. Thus, when the cache is full, the longest unused cache line is replaced. A high cache hit rate can be achieved in ADAS sensor data processing scenarios.

Memory space overview

TC3XX employs an advanced 32-bit architecture, implementing a comprehensive and sophisticated memory system. Its memory space design fully considers the strict requirements of modern automotive electronic systems for high performance, real-time capability, and functional safety. The entire memory system adopts a layered design philosophy, including non-volatile memory (program flash and data flash), multi-level RAM system (local SRAM, global SRAM, and Local Memory Unit LMU), as well as A/B banks. This multi-tiered storage architecture not only ensures efficient data access but also maintains system security and reliability through multiple protection mechanisms.

Furthermore, all bus master agents can access identical peripherals and memories at identical addresses. The system address map is visible and valid for all CPUs, meaning that all peripherals and resources are accessible by all TriCore CPUs and other on-chip bus master agents. Of course, the bus MPU (Memory Protection Unit) can be utilized to configure access controls of different granularity to protect critical memory regions as needed. Specifically, the MPU contains three main protection components: first, eight read-write protected scratch pad memory regions (PSPR, DSPR), which can be independently configured for read-write permissions for each bus master; second, eight read-write protected DLMU (Local Memory Unit) regions, which similarly support master-based permission control; and finally, independent master read enables for accessing the local PFlash Bank (LPB). This multi-level, fine-grained memory system mechanism not only provides sufficient flexibility to meet the requirements of different application scenarios but also ensures the security of system data access.

 DATA ACCESS OVERLAY OVERVIEW(OVC)

Data access overlay is an efficient data access redirection mechanism that allows specific data accesses from the TriCore processor to Program Flash, Online Data Acquisition space, or EBU (External Bus Unit) space to be redirected to overlay memory. These overlay memories can be flexibly configured in multiple locations, including Local Memory, Emulation Memory, EBU space, or DPSR/PSPR memory. A key feature of this mechanism is that it only redirects read and write data accesses without affecting other operations, and performs the redirection without any performance penalty. This design is particularly suitable for scenarios where test and calibration parameters stored in Flash need to be modified dynamically during program runtime, providing a flexible and efficient solution for parameter adjustment and data acquisition in real-time systems. Through this approach, developers can achieve real-time modification and monitoring of critical parameters without interrupting system operation, which has significant application value in embedded systems with strict requirements, such as automotive electronics.

The Overlay function in TC397xx is a powerful and flexible data access redirection mechanism that can redirect data accesses from Program Flash, OLDA, or external EBU space to overlay memory in different locations, including Local Memory (LMU), Emulation Memory, EBU space, and DSPR or PSPR memory. The system supports an overlay memory address range of up to 4MB, with each TriCore core capable of configuring up to 32 Overlay blocks, ranging in size from 32B to 128KB per block. Each block can be independently configured for its memory location and size, and multiple blocks can be enabled or disabled through a single register write operation. The system also provides programmable refresh control for data cache, ensuring synchronization between overlay operations and data loading. Notably, each processor core is equipped with its own independent Overlay system, a design that greatly enhances the system's flexibility and usability, enabling it to meet the requirements of various complex application scenarios.

As shown in the following figure, any data access to segment 0x8H or 0xAH is checked against all activated Overlay blocks. For each activated area, the system compares the address bits with the target base address (OTARx), and this bit-wise comparison is qualified by the content of the OMASKx register. Address bits only participate in the comparison when the corresponding OMASKx bits are set to 1. Access redirection is triggered only when all address bits selected by OMASKx match the corresponding bits in the OTARx register. This mechanism ensures precise address matching and flexible control of overlay ranges.

In TC3xx chips, the combined use of Cache and Overlay requires comprehensive consideration of both performance and reliability. First, it is recommended to keep the program cache (PCACHE) enabled to improve instruction access efficiency, while the data cache (DCACHE) needs to be flexibly configured according to specific Overlay usage scenarios. For Overlay areas that are frequently accessed but rarely updated, enabling cache is recommended to improve access speed; for data areas requiring real-time updates, cache bypass mode can be considered to ensure data timeliness. Regarding data layout, frequently accessed data should be placed in the same Overlay block, and block sizes should be aligned with Cache lines whenever possible to improve cache efficiency. In multi-core scenarios, each core should have its independent Overlay configuration, not only preventing mutual interference but also ensuring the effectiveness of redirection functionality during data access by each core. Meanwhile, when updating Overlay data, attention must be paid to using the cache refresh control provided by DMI to ensure consistency between Cache and memory data. Additionally, necessary error handling mechanisms should be established to address potential Cache synchronization or Overlay access errors. Through these optimization measures, the performance advantages of both Cache and Overlay can be fully utilized while ensuring system reliability.

Example OF DATA ACCESS OVERLAY

Enable Overlay Block for each core.

Overlay Range Select Register for each overlay block and Overlay Enable Register for all cores. Each core has 32 configurable overlay blocks, and the enable and disable of each block corresponds to one bit in the range select register.

Select the redirected address: The RAM address that the CPU will eventually access.

Overlay Range Select Register for each overlay block and Overlay Enable Register for all cores. Each core has 32 configurable overlay blocks, and the enable and disable of each block corresponds to one bit in the range select register.Redirected Address Base Register, OBASE field is used to configure the base address of the calibrated region. It needs to be offset from its base address based on the OMEM type/region selection, and the configuration is supported for RAM regions such as LMU and DSPR.

Select the target address: the DFLASH address of the data accessed by the CPU.

Overlay Target Address Register, the main configuration is the need to remap the address, 0x8h or 0xAh beginning range of the Flash region, such as PFlash, DFlash and the previously mentioned external bus unit address, EBU can be selected to configure here.

Select the size of the Overlay Block area.

Overlay Mask Registers are mainly used to configure the size of an overlay block, a total of 12 bits, as shown in the above figure, the overlay block shall only be 2 n times the size of 32 bytes, the range is from 32B to 128KB.

Application of overlay in xcp protocol stack

XCP OVERVIEW

XCP (Universal Measurement and Calibration Protocol) is an important standardized protocol module in AUTOSAR, primarily used for ECU measurement and calibration. It adopts a master-slave architecture, where testing tools (such as CANape, etc.) serve as masters and ECUs as slaves. XCP supports various communication methods, with CAN-based and Ethernet-based transmission being the most used.

The core functions of the XCP module include data measurement, online calibration, data acquisition (DAQ), memory read/write, and program download. It can monitor ECU internal variables in real-time, modify calibration parameters, and support high-speed data acquisition. In terms of security, XCP provides multi-level protection mechanisms, including calibration protection, DAQ protection, programming protection, and data access protection, ensuring the security of ECU operations.

In practical applications, the XCP module is widely used in multiple stages of automotive electronics development, especially in ECU development, testing, and calibration processes. It not only provides standardized interfaces ensuring compatibility between different tools but also supports flexible configuration options to meet the requirements of different projects. When using XCP, attention must be paid to reasonable resource configuration, real-time requirements, data consistency, and bandwidth limitations. Overall, the XCP module is an indispensable tool in modern automotive electronics development, significantly improving development efficiency and test coverage.

XCP MODULE OF ZC.MUNIU WITH OVERLAY FEATURE

ZC.MuNiu Basic Software Platform has realized the functionality of XCP Module in accordance with AUTOSAR R20-11 specification, and has completed the transplantation and application on TC3XX platform. The measurement and calibration performance is stable and easy to integrate and use, which can effectively support the debugging and calibration needs in automotive electronics development, and help controller development manufacturers to improve efficiency and reduce development difficulties.

In practical applications, one of the most common uses of Data Access Overlay is for calibration functionality. The XCP protocol used in ZC.MuNiu XCP Module essentially provides users with a mechanism to read and write ECU internal memory. Read access ensures that the calibration system can read observables from RAM, known as measurements; write access ensures that the calibration system can modify the values of calibration parameters in RAM, known as calibration.

The procesure of Flash calibration parameters:

1.    At power-on, the initialization of the Overlay function for each core is needed, and the data located in Flash calibration area will be initialized and copied to the specific RAM area mapped by Overlay.

2.    During calibration, the CPU's access to the calibration data operates on the Overlay Block area of RAM.

3.    In the end, through an upper computer tool such as CANape, a calibrated HEX file will be generated and programmed into the FLASH to complete the entire calibration process of the Flash parameters.

MORE PRODUCTS AND FEATURE OF ZC.MUNIU BASIC SOFTWARE PLATFORM

Ø  Compliant with AUTOSAR R20-11 version

Ø  ARTOP architecture upper machine configuration tool, compatible up to AUTOSAR R20-11 version

Ø  Muti-Core Operating System

Ø  Communication Protocol Stack（CAN\LIN）

Ø  Diagnostic Protocol Stack (UDS\J1939)

Ø  Network Management (OSEK\AUTOSAR）

Ø  Calibration Protocol Stack（XCP\CCP）

Ø  Storage Protocol Stack

Ø  Cryptography Module（CRYPTO）

Ø  Custom Development of Complex Drivers

Ø  Engineering Services

 ZC.MUNIU BASIC SOFTWARE ARCHITECTURE

ZC.MUNIU BASIC SOFTWARE PLATFORM ARCHITECTURE

To meet the diverse project requirements of customers and enhance the scalability of the basic software platform, the MuNiu basic software platform has implemented the configurability of each module and has also developed a configuration tool. Customers can complete the configuration of each module according to different needs on the configuration tool, generate configuration code files, and integrate the generated configuration files into the project.

ZC.MuNiu basic software platform configuration tool is based on the Eclipse platform and is built on the ARTOP architecture, which implements the parsing of the AUTOSAR model and ARXML. In addition to the modules defined by the AUTOSAR standard, it also supports OEM and Tie1 manufacturers to develop their own modules for secondary development. After the configuration is completed, the configuration code for each module can be generated.

In the major trends of electrification, connectivity, and intelligence, the number of automotive electronic and electrical components is increasing. The electrical structure is becoming more complex, and the development cycle of the vehicle is continuously shortening. Basic software plays an increasingly important role.

ZC provides development services comply with ASPICE Level 3 processes and functional safety requirements of ASIL-D. ZC also provides customized complex driver software for SBC (Safety Control Board) chips and BCCIC (Battery Cell Control IC) chips. By integrating ZC's functional safety product SafetyFrame, the requirements for functional safety can be satisfied.

ZC has the core technology of the AUTOSAR basic software and can provide on-site support with high quality, fast speed, and low cost.

Click to download the product manual