Functional safety features of Infineon AURIX microcontrollers

This article focuses on hardware features to support functional safety for automotive and industrial applications which are available in the Infineon AURIX family of 32-bit microcontrollers. Comparisons with other microcontrollers and recent trends in microcontroller design are also briefly discussed, including safety related aspects of the whole system which are broader than functional safety features as such.

The Infineon AURIX family comprises two generations of devices: first generation devices (TC2x) with up to 3 cores and running up to 300 MHz in 65nm technology and second generation devices (TC3x) with up to 6 cores running up to 300 MHz in 40nm technology. State of the art technology is currently 28nm with up to 6 cores running at 400 MHz with up to 16 MB internal flash (Renesas announced samples in April 2018 processed at TSMC). The AURIX family MCUs, like most automotive MCUs from competing manufacturers (Renesas, NXP, STMicro, …) are designed to support ASIL-D safety requirements as defined by the ISO26262 standard.

With ever increasing technology scaling and increasing level of integration (functionality of several chips can be combined on one chip), it becomes more and more difficult to provide proper software encapsulation of the different applications. Other recent trends are Over-The-Air software upgrade (OTA) and more complex and powerful diagnostics capabilities, requiring higher levels of security because of possible safety impact. Wireless communication also helps to improve safety by providing vehicle-to-vehicle and vehicle-to- infrastructure communication but simultaneously creates the risk of potential intrusion which could compromise safety (e.g. a malicious hacker could cause the car to crash).

Another development is the use of a hypervisor, a virtualization technique enabling different virtual machines to run on a common underlying platform (a powerful MCU). This allows a safety critical AUTOSAR based application and a safety agnostic infotainment linux application to run on the same underlying platform. Recent MCUs even provide hardware support for virtualization. When turning to hardware features for functional safety, taking the AURIX TC27x as an example, the most distinctive safety feature consists of the multicore architecture (3 cores in this case). This allows to split the overall software in different parts running on separate cores, increasing the “freedom from interference” level between safety critical software modules and less critical modules. Two out of the 3 cores have lockstep functionality: a second instance of the core runs in parallel and outputs are compared. The lockstep mechanism is enabled at boot time and can not be disabled afterwards. Errors can be injected in the mechanism to ensure it is properly detecting errors. This is an example of a built- in self-test which is also provided for many other safety features. The checker core not only runs with a small delay compared to the main core but also differs on the levels of architecture and layout to eliminate common cause failures as much as possible.

The AURIX MCU features a centralized safety management unit which allows to configure different safety actions based on software and hardware faults or alarms detected in the different safety modules. It controls a protection mechanism for safety critical registers in other chip modules, which protects those registers against accidental writes or random bit failures by continuously monitoring their contents. An interesting feature is the prevention of a double application reset: when this is detected the chip is held in reset until a power-on or other reset occurs. This prevents the chip from continuously rebooting. Apart from resetting the whole chip, it is also possible to reset individual modules on the chip. It goes without saying that re-initialing only a part of the hardware or software system becomes ever more important as more functionality gets integrated on the same MCU. The second AURIX generation features an additional 8-bit CPU which can keep limited functionality (non-safety related) running in standby mode and even during a watchdog reset of the rest of the system (including the main cores).

Several access protection mechanisms related to the main system bus are configurable for each bus master. Each master has a unique identification tag which is used in the applicable access protection registers. The on-chip bus has error detection system with a test feature to invert bits in different phases of a bus transaction so that its correct functioning can be tested. CPU special function registers can be configured to be writable only by one or more specific masters to protect them from being corrupted. In SRAM modules local to each core as well as in the shared LMU memory, 8 regions can be configured to be protected from write access from unwanted bus masters.

The ECC (error-correcting code) implementation is able to correct single errors and detect all double errors and a high rate of triple errors. An additional error detection mechanism is provided for the address decoder which can not be detected by the ECC. Flash memory is also protected by several safety features: master specific access control, restriction of commands and read/write protection. Each sector in the program flash can be individually protected against write access and can even be locked forever (OTP). An oscillator watchdog is able to detect significant clock frequency deviations of the oscillator module. A primary and secondary power supply monitoring circuit are monitoring the voltage supply for over- and under-voltage. Thresholds are configurable via registers which can be locked by the security module to prevent tampering with the system by manipulating the power supplies. Watchdog timers are used for standard watchdog functionality (a common system level watchdog and individual CPU watchdogs are provided) and to protect critical registers with an “end-of-initialization” mechanism: when access is granted again to those critical registers, only a limited time window is available for write access. A password and guard bits are required to gain access to the related configuration registers.

A dedicated hardware security module provides hardware acceleration support for the latest cryptographic security algorithms, allowing to store the keys in a dedicated flash memory and providing a “firewall” towards the rest of the system. This module has its own ARM 32-bit CPU. Convergence between security and safety is becoming ever more important as mentioned before. We can conclude that semiconductor manufacturers are very active in adding clever safety features on automotive MCUs to keep functional safety under control while increased integration levels allow for more and more software functionality to run on one SoC while at the same time keeping costs under control.