Overview

FS85 is a kind of automotive grade SBC chip introduced by NXP to meet the functional safety requirements. The FS85 series SBC has the highest functional safety level ASIL-D, and is mainly used in automotive applications such as automotive radar, ADAS domain controller, and in-vehicle entertainment information system. This paper will briefly introduce the FCCU function of the chip, including the function introduction of FCCU, the FSP protocol supported by FCCU, the configuration method of FCCU and the example of FCCU application scenario.

1      the function introduction of FCCU

The FCCU provides a hardware interface to collect fault information from the MCU and place the device in a safe state if a device fault is detected. No CPU intervention is required during the collection and control operations. FCCU provides a systematic approach to fault collection and control. The FS85 chip supports two fault signal inputs FCCU1 and FCCU2 for collecting fault information from MCU, and support single and double wire FCCU fault monitoring.

2      FCCU BI-STABLE protocol

Under the Bi-stable protocol, the FCCU fault can also be judged by configuring the fault polarity of FCCU12, which can be configured as FCCU1 = 0 or FCCU2 = 1 to belong to the fault state, or as FCCU1 = 1 or FCCU2 = 0 to belong to the fault state.

3      FS85 FCCU configuration method

3.1     FCCU FUNCTION ENABLED

The FCCU monitoring function of FS85 must be enabled by using the FCCU_EN OTP bit through the OTP. If FS85 is used in combination with NXP S32 series chips and FCCU monitoring is enabled, the FS85 fault recovery function can be enabled by OTP using the FLT_RECOVERY_EN OTP bit, thus using the fault recovery strategy of the microcontroller.

3.2     Hardware configuration of FCCU

3.2.1        Hardware configuration by pair

To enable FCCU (bi-stable mode), the FCCU_CFG bit of the FS_I_SAFE_INPUTS register is set to 01.

3.2.2        Hardware configuration as single independent input

Enabling a single input to the FCCU requires setting the FCCU_CFG bit of the FS_I_SAFE_INPUTS register to 10/11.

3.2.3        Fault polarity configuration

When the input is configured in the pin-pair input mode, the polarity of the error signal can be configured via the FCCU12_FLT_POL bit.

When configured in separate input mode, the FCCU can detect 2-channel error signals, and the polarity of each channel error signal can be configured separately by FCCU1_FLT_POL and FCCU2_FLT_POL.

3.2.4        FCCU12 error impact configuration

The error response of the FCCU is configured through FCCU12_FS_IMPACT when the input is configured in the pin-pair input mode.

When configured in separate input mode, the error response of the FCCU is individually configured via FCCU1/2_FS_IMPACT.

3.2.5        MCU fault recovery strategy

The fault recovery strategy feature is enabled by OTP_FLT_RECOvERY_EN bit. This function extends the watchdog window to allow the MCU to perform a fault recovery strategy. The goal is to not reset the MCU while it is trying to recover the application after a failure event. When a fault is triggered by the MCU via its FCCU pins, the FSOB pin is asserted by the device and the watchdog window duration becomes automatically an open window (no more duty cycle). This open window duration is configurable with the WDW_RECOVERY [3:0] bits during the INIT_FS phase.

4      FCCU state machine

The transition from WDW_PERIOD to WDW_RECOVERY happens when the FCCU pin indicates an error and FSOB is asserted. If the MCU send a good watchdog refresh before the end of the WDW_RECOVERY duration, the device switches back to the WDW_PERIOD duration and associated duty cycle if the FCCU pins does not indicate an error anymore. Otherwise, a new WDW_RECOVERY period is started. If the MCU does not send a good watchdog refresh before the end of the WDW_RECOVERY duration, then a reset pulse is generated, and the fail-safe state machine moves back to INIT_FS.

5      Example of application scenario of FCCU

Application Scenarios：TC397_SMU + FS8530_FCCU

FCCU configuration：

FS_I_SAFE_INPUTS. FCCU_CFG = 01（Bi-statble）、

FS_I_SAFE_INPUTS. FCCU12_FLT_POL = 0 （FCCU1 = 0 or FCCU2 = 1 level is a fault）

FS_I_SAFE_INPUTS. FCCU12_FS_IMPACT = 0（FS0B only is asserted）

FS_WD_WINDOW. WDW_RECOVERY = 0x7（12ms）

Test Result：

6      ZC TC3XX SAFETYFRAME Product Introduction

The electrification and intelligent development of automobile electronic control system is becoming more and more complex, and the safety requirements of electronic and electrical architecture are becoming higher and higher. Through HARA analysis of road vehicle application scenarios, more and more attention is paid to vehicle functional safety in order to degrade and decompose safety objectives and keep the possibility of hazard occurrence lower than the risk limit. In recent years, reference has been made to ISO 26262 for functional safety standards; Refer to E-GAS layering for the software shelf security architecture. In electronic and electrical systems, For the common Element, the SEooC (safety element out of context) approach is usually adopted for its design and development.

ZC launched SAFETY FRAME to provide customers with ASIL level decomposition consultation, FMEDA analysis process support, chip-level self-check safety mechanism development, SafetyFrame configuration and software integration and other full-process functional safety services.

SAFETY FRAME consists of 3 components: the internal module self-checking test component of MCU (i.e. SF.MCU), the driver component of SBC's hardware security mechanism (i.e. SF.SBC), and the safety architecture component (i.e. SF.Architecture). The core module of SF.Architecture is Test Manager, which is used for the scheduling management of Safety Library for MCU and SBC, including Safety Wdgm, scheduling of Safety SBC/ASIC driver modules, and interfaces with application layer PFC (Program Flow Check), etc. SF.MCU contains 3 major modules:

l  TestLib-- Implementation of MCU chip module inspection.

l  DriverLib-- Implements the MCU chip module driver.

l SwLib-- Interfaces such as digital signature database and end-to-end protection database are commonly used by users.

In the principle of software modular layering, Function Controller and Monitoring Controller are implemented by SF.MCU and SF.SBC, respectively. It is also deployed at EGAS Level2 and Level3 levels, taking into account the application requirements of program flow monitoring and shutdown path design.

Software Architecture

The functional safety modules implemented by ZC SafetyFrame products include: Test Manager module, LBIST Test module, MBIST Test module, PFlash Test module, MCU Firmware Test module, Register Test module, DMA Test module, SRI Error Handling module, MONBIST Test module, Mcu Register Monitor module, Register Monitor Test module, Evadc Test module, Interrupt monitor Test module, Clock Plausibility Test module, DAM Test module, Convctrl Test module, CPU Internal BUS Test module, STM Test module, GTM TIM Clock Test module, Gtm IOM Alarm Test module, Gtm Tom Tim Test module, Port Test module, GptTst module, PMS configuration module, DTS Configuration module, OSC Clock Monitor module, SMU Error Handler module, SMU Software Alarm Drv module, IR FFI Control module, GTM IOM Configuration module, ERU Configuration module, TLF35584 Driver module, TLF35584 Error Handler module, E2E protection module, Safe Watchdog Manager module, Safe Watchdog Interface module, Safe Internal Watchdog module, Safe SBC Watchdog module.

ZC’s SafetyFrame product implements the watchdog monitoring WDGM module for the FS85 chip mentioned in this paper, and implements the SMUErrHdl module with the FCCU function in the TC3XX SMU module. The module implements the following security mechanisms.