NXP Semiconductors MPC5777M Safety Manual
NXP Semiconductors
Document Number: MPC5777M_GMSM
Safety Manual
Safety Manual for MPC5777M
Rev. 1.1, 10 Apr 2017
Table of Contents
1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
2.1 Mission profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
2.2 Functional safety – ISO 26262 compliance. . . . . . . . . . . 4
2.3 Safety goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
2.3.1 Safe state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
2.4 Correct operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
2.5 Failure indication signaling . . . . . . . . . . . . . . . . . . . . . . .6
2.6 Failure indication time . . . . . . . . . . . . . . . . . . . . . . . . . . .7
2.6.1 Minimum failure indication time . . . . . . . . . . . . . .7
2.7 Failure handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Functional safety requirements for application software. . . . . .9
3.1 Disabled modes of operation . . . . . . . . . . . . . . . . . . . . .9
3.1.1 Debug mode . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
3.1.2 Test mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2 Initial checks and configurations . . . . . . . . . . . . . . . . . .10
3.2.1 I/O ball configuration . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 MCU configuration. . . . . . . . . . . . . . . . . . . . . . .11
3.2.3 Mode Entry (MC_ME) . . . . . . . . . . . . . . . . . . . .12
3.2.4 Start-up configuration check . . . . . . . . . . . . . . .13
3.2.5 Dual core lockstep mode . . . . . . . . . . . . . . . . . .13
3.2.6 FCCU fault reaction configuration . . . . . . . . . . .13
3.2.7 Reset Generation Module (MC_RGM) . . . . . . .15
3.2.8 Self-test completion . . . . . . . . . . . . . . . . . . . . . . 17
3.2.9 MEMU initial checks . . . . . . . . . . . . . . . . . . . . .20
3.2.10 Flash memory configuration and tests. . . . . . . . 20
3.2.11 Voltage monitor configuration . . . . . . . . . . . . . .21
3.2.12 Temperature monitoring configuration . . . . . . . .23
3.2.13 Clock monitoring configuration . . . . . . . . . . . . .24
3.2.14 System clock availability . . . . . . . . . . . . . . . . . .25
3.2.15 Clock Generation Module (MC_CGM). . . . . . . . 25
3.2.16 PLL generated clocking . . . . . . . . . . . . . . . . . . .26
3.2.17 XBAR configuration . . . . . . . . . . . . . . . . . . . . . .26
3.2.18 Platform flash memory controller. . . . . . . . . . . .26
3.2.19 Wake-Up Unit (WKPU) / External NMI . . . . . . .27
3.2.20 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
3.2.21 Software Watchdog Timer (SWT) . . . . . . . . . . . 27
3.2.22 Analog to Digital Converters . . . . . . . . . . . . . . .28
3.2.23 Temperature sensor (TSENS) . . . . . . . . . . . . . .30
3.3 Runtime checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 General requirements . . . . . . . . . . . . . . . . . . . .30
3.3.2 CRC of configuration registers. . . . . . . . . . . . . .31
3.3.3 XBAR usage . . . . . . . . . . . . . . . . . . . . . . . . . . .32
3.3.4 System Memory Protection Unit (SMPU) . . . . .32
3.3.5 Platform flash memory controller. . . . . . . . . . . .33
3.3.6 Flash memory . . . . . . . . . . . . . . . . . . . . . . . . . .33
3.3.7 PRAMC configuration . . . . . . . . . . . . . . . . . . . .35
3.3.8 RAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.9 ECC Bypass using core registers and Indirect
Memory Access (IMA)38
3.3.10 Decorated Storage Memory Controller (DSMC) 39
3.3.11 Interrupt management . . . . . . . . . . . . . . . . . . . 39
3.3.12 eDMA usage . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.13 Reset Generation Module (MC_RGM). . . . . . . 40
3.3.14 Detection of unwanted resets. . . . . . . . . . . . . . 41
3.3.15 Periodic Interrupt Timer (PIT). . . . . . . . . . . . . . 47
3.3.16 System Timer Module (STM) usage . . . . . . . . 47
3.3.17 I/O and Peripheral Bridge. . . . . . . . . . . . . . . . . 47
3.3.18 System Integration Unit Lite (SIUL2) . . . . . . . . 50
3.3.19 GTM Wrapper. . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.20 External Bus Interface (EBI). . . . . . . . . . . . . . . 50
3.3.21 Reading analog inputs . . . . . . . . . . . . . . . . . . . 51
3.3.22 Software Watchdog Timer (SWT) usage . . . . . 51
3.3.23 Communication peripherals . . . . . . . . . . . . . . . 51
3.3.24 Temperature sensor (TSENS) . . . . . . . . . . . . . 52
3.3.25 Analog to Digital Converters . . . . . . . . . . . . . . 52
3.3.26 Mode Entry (MC_ME) . . . . . . . . . . . . . . . . . . . 55
3.3.27 Semaphores (SEMA42) . . . . . . . . . . . . . . . . . . 55
3.4 Operational interference protection . . . . . . . . . . . . . . . 55
3.4.1 Core Memory Protection Unit (CMPU) . . . . . . . 55
3.4.2 System Memory Protection Unit (SMPU) . . . . . 56
3.4.3 AIPS protection mechanism. . . . . . . . . . . . . . . 56
3.4.4 Register protection (REG_PROT) . . . . . . . . . . 57
3.4.5 Performance (Core_1) and Peripheral (Core_2)
Cores57
4 Functions of external devices for ASIL D applications . . . . . 58
4.1 External reset output . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 High impedance outputs . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 External Watchdog (EXWD) . . . . . . . . . . . . . . . . . . . . 59
4.4 Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5 Error Out Monitor (ERRM) . . . . . . . . . . . . . . . . . . . . . . 60
4.5.1 Both FCCU pins connected to external device. 61
4.5.2 Single FCCU pin connected to external device 61
5 Address decoding coverage . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Test implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Obtaining the list of locations to be read . . . . . . . . . . . 69
Memories including block address decoding75
5.4 Test result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Multiple single bit error in the same word-line79
6 Testing All-X in RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.1 Candidate address for testing All-X issue . . . . . . . . . . 81
6.2 ECC checkbit/syndrome coding scheme . . . . . . . . . . . 86
7 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.1 Conventions and terminology . . . . . . . . . . . . . . . . . . . 91
7.2 Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . 91
8 Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors2
Preface
1Preface
Assumption: This document provides guidelines for the proper use of the MPC5777M Microcontroller
Unit (MCU) in ASIL D applications. It will help guide the user with the steps necessary to integrate the
MPC5777M into their application.
Assumption: The MPC5777M will be used as a component within a safety related application. T o allow
an analysis of the MCU's capability to reach the required safety level, assumptions have been made
(following the concept of SEooC described in the ISO26262). These assumptions are on the scope of the
MCU (for example, including external components interacting with the MCU) and on its usage by
application software. The FMEDA provided with the MPC5777M was conducted under inclusion of these
assumptions.
Assumption: [SCG18.098]A typical safety function operates by reading input from the MPC5777M's I/O
facilities (including network connections), processing this input possibly using, generating, and storing
results valid for several calculation cycles, and sending output to other system components (for example,
actuators or other MCUs) again using the MPC5777M's I/O facilities [end].
This document considers:
• The system assembly that contains the MPC5777M MCU
• The “Safety Element out of Context” section in the “Road vehicles - Functional safety - Part 10:
Guideline [ISO 26262-10:2012]” standard
• Certain assumptions about the assembly's functional safety needs based on that standard
and determines whether a measure is an assumption or not based on these factors.
What this means for designers using the MPC5777M is that if they don’t fulfill a specific Safety Manual
(SM) assumption they have to show that their alternative solution is similarly efficient concerning the
safety requirement in question (for example, provides the same coverage, avoids Common Cause Failure
(CCF) as effectively, and so on), show that the particular issue is irrelevant for their application (for
example, the module is not used), or estimate how much the failure rate increases and the failure metrics
(SPFM/LFM) decrease due to the deviation. Otherwise, the FMEDA provided with the MPC5777M is not
valid.
This document also contains guidelines on how to configure and operate the MPC5777M for ASIL D
applications. These guidelines are preceded by one of the following bold text statements:
• Implementation hint
• Recommendation
NOTE
Further information about safety configuration and operation can be found
in the MPC5777M Reference Manual’s “Functional Safety” chapter.
These guidelines are considered to be useful approaches for the specific topics under discussion, but are
not mandatory . The user will need to use discretion in deciding whether these measures are appropriate for
their applications.
This document is only valid under the assumption that:
NXP Semiconductors 3
Safety Manual for MPC5777M, Rev. 1.1
General information
• Assumption: [SCG18.170]the MPC5777M is used in automotive applications for use cases
requiring a fail-silent or a fail-indicate MCU. [end]
• the environmental conditions given in the MPC5777M Data Sheet are maintained.
As for all devices, device errata must be taken into account during system design and implementation. For
a safety-related device such as the MPC5777M, this also concerns safety-related activities such as system
safety concept development. The FMEDA and Safety Concept are valid if the listed assumptions in the
text are covered.
Assumption: [SM_FMEDA_131] All relevant hardware safety mechanisms are enabled and configured
correctly when using any of the information in this document. [end]
General failure rate, or even an FMEDA (Failure Modes, Effects & Diagnostic Analysis) report, is
available upon request when covered by a NXP Semiconductors NDA (contact your NXP Semiconductors
representative).
2 General information
2.1 Mission profile
Lifetime for a MPC5777M is 20 years which is equivalent to 20000 hours of active operation for the MCU.
The assumed mission profile is:
• Lifetime: 20 years
• Total operating hours: 20000 hours
• Assumption: [SCG18.002] Trip time (driving cycle): 12 hours [end]
— This is the maximum time of operation of the MPC5777M without a start-up reset.
• Assumption: [SCG18.003] Fault-Tolerant Time Interval (FTTI, also known as Process Safety
Time, PST) = 10 ms[end]
— FTTI is the time the controlled system will not transition to a hazardous state, despite the
MPC5777M failing.
NOTE
This is a conservative estimate since the actual number depends on MCU
application (See Section 2.6, Failure indication time, for exact calculation
instructions).
The MPC5777M was designed to work within a maximum operational temperature profile (see the
Qorivva MPC5777M Microcontroller Data Sheet).
Assumption: [SM_FMEDA_001] The device is to be handled according to JEDEC standards J-STD-020
and J-STD-033. [end]
2.2 Functional safety – ISO 26262 compliance
Assumption: [SCG18.201]The MPC5777M MCU was developed in accordance with ISO 26262 as a
Safety Element out of Context (SEooC). [end]
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors4
General information
The MPC5777M is suitable to be used in safety-relevant applications including systems that are classified
as ISO 26262 ASIL A, ASIL B, ASIL C or ASIL D.
Assumption: [SCG18.202]The development process of the MPC5777M fulfills ASIL D requirements of
ISO 26262. [end]
2.3 Safety goals
The safety goals of the MCU are defined as follows:
• [SCG18.100]The primary safety goal is that the MPC5777M does not leave its safe states for
intervals equal or longer than the FTTI (10 ms) unless configured by the application software to do
so. [end]
• [SCG18.101]The secondary safety goal is that the MPC5777M, or the software running on the
MPC5777M, shall be able to detect the permanent unavailability of any safety mechanism that is
necessary to achieve the primary safety goal, and this shall be done at least once per driving cycle
(12 hours). [end]
The ASIL for the first goal is D, for the second it is B.
2.3.1 Safe state
A Safe state of the system is named Safe state
Safe state
. A Safe state
MCU
of a system is an operating mode without an unreasonable probability of
system
whereas the Safe state of the MPC5777M is named
system
occurrence of physical injury or damage to the health of persons.
Assumption: [SCG18.004]The safety goals are achieved by transitioning or holding the MPC5777M in
the following Safe state
MCU
:[end]
• Assumption: [SCG18.005]Completely unpowered [end]
• Assumption: [SCG18.006]In reset [end]
• Assumption: [SCG18.007]Operating correctly (See Section 2.4, Correct operation) [end]
• Assumption: [SCG18.008]Explicitly indicating an internal error [end]
If the MPC5777M continuously switches between a standard operating state and the reset state, without
any device shutdown, the MCU is not considered to be in a Safe state
(See Section 3.2.7, Reset
MCU
Generation Module (MC_RGM) for details).
Assumption: [SM_FMEDA_002] The application shall identify and signal such switching as a failure
condition. [end]
If the MPC5777M signals an internal failure via its error out signals (FI[0], FI[1]), the surrounding
subsystem should no longer use the MPC5777M outputs for safety functions since these signals are no
longer considered reliable. This means that if an error is indicated, the system must be able to remain in a
Safe state
without any additional actions by the MCU. Depending on its configuration, the system
system
may disable or reset the MCU as a reaction to the error signal.
Assumption: [SCG18.009]It is assumed that the system reacts safely to the MPC5777M being in or
entering all safe states shown in Section 2.3.1, Safe state. [end]
NXP Semiconductors 5
Safety Manual for MPC5777M, Rev. 1.1
General information
2.4 Correct operation
Assumption: [SCG18.010]Correct operation of the MPC5777M is defined as: [end]
• Assumption: [SCG18.01 1]V ital system modules (ViMos) and other supporting modules (SuMos)
are operating according to specification. [end]
• Assumption: [SCG18.012]Peripheral modules (PeMos) are operating according to specification.
[end]
• Assumption: [SCG18.013]Non-safety modules (NoSaMos) are not interfering with the operation
of other modules. [end]
• Other support modules (SuMo) are safety-relevant and in principle potential members of the
V iMos category , and cannot lead to a violation of the safety goal on their own. T ypically, these will
only have multiple point faults, but not single point faults.
NOTE
[SCG18.902]See “Module classification” table in the MPC5777M
Reference Manual’s “Functional Safety” chapter for specific module safety
classification. [end]
2.5 Failure indication signaling
The Fault Collection and Control Unit (FCCU) offers a hardware channel to collect errors and to bring the
device to a Safe state
when a failure is present in the device. The FCCU provides two error output pins
MCU
(bidirectional FI[0] and FI[1], on PB[11] and PC[2], respectively) as a failure indication to the external
world.
Different protocols for the error output pins are supported:
• Dual rail protocol
• Time switching protocol
• Bi-stable protocol
If bi-stable protocol is selected, it is possible to use only one of the two error output pins on the
MPC5777M. Since the pin multiplexing that is utilized for each of the error output signals works
differently, FI[0] should be the signal used in this configuration.
After start-up reset, the error output signal FI[0] is in high impedance while FI[1] is functionally a GPIO
input with a weak pullup. The error output pins transition to the operational state only on software request.
A functional reset has no influence on FI[0] but sets FI[1] to high impedance with a pullup. To avoid
changing FI[1] during functional reset when time switching or bi-stable protocol is used, it is
recommended to write 0 to FCCU_CFG[PS].
Refer to Section 4.5, Error Out Monitor (ERRM) for details on specific requirements for connecting FI[0]
and FI[1] to an external device.
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors6
General information
2.6 Failure indication time
Failure indication time is the time it takes from the occurrence of a failure to when the indication of that
failure is visible by driving the error out pins or by assertion of reset.
The failure indication time of the MPC5777M is finite. It must be taken into account when determining
application safety strategies since failure indication time plus reaction time on this indication by the system
must be less than the FTTI.
[SCG18.128]Failure indication time has three components, two of which are influenced by certain
configuration choices:
Failure indication time = recognition time + internal processing time + indication time.
Each component of failure indication time is briefly described as follows:
• Recognition time is the maximum of the recognition time of all involved safety mechanisms. The
two mechanisms with the longest times are:
— Recognition time related to the FMPLL loss of clock: This time depends on the FMPLL
configuration. This time is approximately 20 µs.
— Diagnostic cycle time of software self-tests. This time depends closely on the software
implemented.
• Internal processing time lasts a maximum 10 IRCOSC clock cycles (nominal frequency of
IRCOSC is 16 MHz).
• Indication time is the time to notify an observer about the failure. This time depends on the
indication protocol in the FCCU:
— Dual Rail protocol and time switching protocol –
— FCCU configured as “fast switching mode”: indication delay is
maximum 64 µs. As soon as the FCCU receives a fault signal, it
reports the failure to the outside world via an output pin (if properly
configured).
— FCCU configured as “slow switching mode”: an indication delay
could occur . The maximum delay is equal to the period of the error
out signal, which toggles at a frequency of 61 Hz.
— Bi-stable protocol: indication delay is maximum 64 µs. As soon as the FCCU receives a fault
signal, the FCCU reports the failure via an output pin (if properly configured).
If the configured reaction to a fault is an interrupt, an additional delay (interrupt latency) can occur until
the interrupt handler is able to start executing (for example, higher priority IRQs, XBAR contention,
register saving, and so on). [end]
Assumption: [SCG18.022]The overall failure indication time shall be less than the FTTI of the
application (assumed FTTI shown in Section 2.1, Mission profile). [end]
2.6.1 Minimum failure indication time
When a failure event occurs, one or both error output signals (Fn) are set to show an error condition for a
minimum time (T_min), even if software attempts to reset the state of the error out signals. The external
NXP Semiconductors 7
Safety Manual for MPC5777M, Rev. 1.1
General information
failure indication stays in failure mode for a configurable minimum time as shown in Equation 1. For
bi-stable protocol the time DELTA_T is configurable by software up to a maximum of 10 ms by
configuring FCCU_DELTA_T[DELTA_T].
T_min = 250 μs + FCCU_ D E LTA_T[DELTA _ T ] μs Eqn. 1
In case another failure event happens within T_min after the first failure event, the timer measuring T_min
is restarted.
2.7 Failure handling
The FCCU is responsible for reacting to internal failures. A different reaction can be configured for each
failure source.
Failure sources include:
• All failure indication signals from the modules within the MCU
• Control logic and signals monitored by the FCCU itself
• Software-initiated failure indications
• External failure input (via FI[0] pin)
The different failure sources, as represented by the FCCU failure inputs, are shown in “FCCU failure
inputs” table in the “Functional Safety” chapter of the MPC5777M Reference Manual.
Available failure reactions include:
• Maskable interrupt
• Non-maskable interrupt
•Reset
• Change the state of the failure indication pin(s)
• No reaction
Additionally, the transmission capabilities of the communication controllers can be disabled when the
FCCU transitions to the error state (see “Disabling of communication controllers” in the “Functional
Safety” chapter of the MPC5777M Reference Manual).
Software can read the failure source that caused a fault from the FCCU_RF_S[0:3] registers and can do so
either before or after a functional reset. Software can also reset the failure by resetting the respective status
bit, but the external failure indication will stay in failure mode for a configurable amount of time (see
Equation 1).
Error handling can be split into two categories:
• Handling of errors during runtime
• Handling of errors during boot-time (for example, LBIST, MBIST)
Assumption: [SM_FMEDA_003] Runtime errors shall be handled in a time shorter than the FTTI. [end]
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors8
Functional safety requirements for application software
Assumption: [SM_FMEDA_004] Boot-time failure handling shall be handled before the safety function
starts execution. T ypically, the reaction is to not let the safety function start and give a failure indication to
the user. [end]
3 Functional safety requirements for application
software
This section gives an overview of the necessary or recommended measures when using the individual
components of the MPC5777M. If a module in the MPC5777M is used without following the required
actions, there is a risk that the safety certificate for the entire MCU, or other modules if the failure
interferes with their operation, may be invalidated.
It is possible to ignore the required measures if equivalent measures to manage the same failures are
alternatively included.
Modules not explicitly covered by this document do not require any safety specific software measures.
T o assist continuous product improvement, it is recommended to report field failures which occur despite
following these measures to NXP Semiconductors in accordance with ISO 26262-7 Chapter 6.4.2.1.
3.1 Disabled modes of operation
The system and application software must ensure that the functions described in this section are not
activated while running safety-relevant operations.
3.1.1 Debug mode
The debugging facilities of the MPC5777M are a potential source of failure when activated during the
operation of safety-relevant applications. They can halt the cores, cause breakpoint hits, write to core
registers and the address space, and activate boundary scan. The MCU must therefore not enter debug
mode to avoid interference with the normal operation of the application software.
The state of the JCOMP pin determines whether the system is being debugged or whether the system
operates in normal operating mode. When the JCOMP pin is logic low , the JTAGC TAP controller is kept
in reset for normal operating mode. When it is logic high, the JTAGC TAP controller is enabled and the
system can enter debug mode if requested. The system must ensure that it does not attempt to enable debug
mode by externally asserting the JCOMP pin during boot up. Otherwise, a fault condition signal will be
sent to the FCCU.
Assumption: [SCG18.023]Debugging will be disabled in the field while the device is being used for
safety-relevant functions. [end]
Assumption: [SCG18.024]For normal operation, software needs to configure any module that is safety
relevant (such as SWT) to continue execution during debug mode and to not freeze the module operation
if debug mode is entered. [end]
NXP Semiconductors 9
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
3.1.2 Test mode
Several mechanisms of the MPC5777M can be circumvented in test mode, undermining the safety
concept. Test mode is used for comprehensive factory testing and should not be used in normal operating
mode.
The TEST pin is for testing purposes only and should be allowed to float in the user application. The
system must ensure the TEST pin is not asserted during boot to enable test mode. (The TESTMODE pad
has an internal pull-down that is always active to keep it from asserting during normal operation.) The
activation of test mode is supervised by the FCCU and will signal a fault condition when test mode is
entered.
Assumption: [SCG18.025]Test mode will be disabled in the field while the device is being used for
safety-relevant functions. [end]
T o avoid unwanted activation of the testing circuitry the Design For T estability (DFTn) FCCU error inputs
must be enabled even if they are not needed by the application. The FCCU channels for DFT[1:4] are 46
to 49, respectively . These error inputs are enabled by setting the appropriate bits in the following registers:
• FCCU_RF_CFG
• FCCU_RFS_CFG
• FCCU_RF_TOE
• FCCU_RF_E
• FCCU_IRQ_ALARM_EN
• FCCU_NMI_EN
• FCCU_EOUT_SIG_EN
3.2 Initial checks and configurations
After start-up, the application software must ensure the conditions described in this section are satisfied
before safety-relevant functions are enabled. Additional configuration is needed to ensure freedom from
interference between cores and between concurrent software (see Section 3.4, Operational interference
protection).
3.2.1 I/O ball configuration
Assumption: [SCG18.120]The user shall avoid configurations that place redundant signals on
neighboring pads or pins. [end]
[SCG18.121]T o determine whether two functions on two package balls are adjacent to each other , refer to
the mechanical drawings of the packages (see the MPC5777M Data Sheet) together with the spheres
(balls) number information of the packages as seen in the MPC5777M Reference Manual’s “System
Integration Unit Lite2 (SIUL2)” section together with the ball information provided in the document
"MPC5777M_System_IO_Description_and_Input_multiplexing_tables" that is attached to the
MPC5777M Reference Manual. [end]
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors10
Functional safety requirements for application software
3.2.2 MCU configuration
Assumption: [SCG18.051]Safety software running on the Safety Core shall check correct initialization of
the MPC5777M before activating the safety-relevant functionality. [end]
NOTE
See the “DCF Client List” table in the “Device Configuration Format (DCF)
Records” chapter of the MPC5777M Reference Manual for details.
See the “IOP applies device settings” section in the “Reset and Boot”
chapter of the MPC5777M Reference Manual for details on the IOP phase
of the boot
Assumption: [SM_FMEDA_005]FMEDA assumes that the device is properly configured by the DCF
records in the UTEST sector of the flash memory to enable the Hardware Security Module (HSM)
I/O Processor (Core 2) handshaking during the boot phase. [end]
NOTE
See the “Reset sequence flow based on initial device condition” section of
the “Reset and boot” chapter of the MPC5777M Reference Manual for
details.
The MCU memory configuration and the JT AG Part ID number can be read in the SSCM_MEMCONFIG
register (JTAG Part ID = SSCM_MEMCONFIG[JPIN]).
This information is normally used for debugging purposes, and is not necessary for the safety function.
Assumption: [SM_FMEDA_006]Application software does not use the JTAG Part ID, nor does it affect
safety critical operations. [end]
With the System Status and Configuration Module (SSCM) it is possible to configure different MCU
behaviors (for example, determine primary and HSM boot vector, abort disable/enable).
Assumption: [SM_FMEDA_008]SSCM shall be configured to trigger an exception in case of any access
to a peripheral slot not used on the device (SSCM_ERROR register). [end]
Assumption: [SM_FMEDA_009]After boot has completed, the application should perform an access to
unimplemented memory space and check for the expected abort to occur. [end]
The FCCU can be configured to trigger a NMI to the Safety Core if a fault is detected. In the case of a
functional reset, this NMI is masked by hardware and is unmasked during BAF execution. The NMI
service routine is executed as soon as the Safety Core is activated.
In the worst case, this flow can cause an unwanted functional reset loop. For example, assume a situation
which can not be recovered by software, and the NMI service routine can only trigger a functional reset.
After the reset, the BAF unmasks the NMI which triggers the Safety Core. Which cause the NMI to
execute again.
Assumption: Pending FCCU faults shall be cleared before enabling the Safety Core after a functional
reset.
NXP Semiconductors 11
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
From an application standpoint this means:
1. Do not activate the Safety Core automatically during or after the BAF.
2. Initialize the FCCU (may be preceded by a software reset of the FCCU).
3. Activate the Safety Core.
3.2.3 Mode Entry (MC_ME)
To overcome faults in the wakeup and interrupt inputs to the MC_ME, the following is assumed if the
application uses Low Power mode (LP):
• Assumption: [SM_FMEDA_010] The duration in LP mode is monitored. If the system does not
wake up within a specified time frame, the system will be reset by the monitor (for example, SWT
can provide the time monitoring). [end]
• Assumption: [SM_FMEDA_011]Software will perform a test of entry and exit to and from LP
mode at startup. [end]
An incorrect clock source as the system clock could be selected due to faults, resulting in multiple faults.
In order to improve detection of such faults, and the effect by the clock monitors:
• Assumption: [SM_FMEDA_012]It is assumed that the nominal frequency of different clock
sources that are available as the system clock have different frequencies. [end]
The mode configuration registers of MC_ME take effect only when the mode transition request is initiated.
Thus, instead of the configuration registers the global status register should be CRCed (if configuration
register CRCing is done) as that represents the current state.
Assumption: [SM_FMEDA_013] Application software shall check the target mode configuration
immediately before issuing a mode transition request. [end]
Assumption: [SM_FMEDA_014] In order to check that a mode transition has been correctly executed,
after initiating a mode transition request, software shall verify the mode transition status within the
expected completion delay . Also, the new configuration is compared with the intended configuration. This
does not apply if the target mode transition is to LP mode. [end]
NOTE
The MC_ME implements a register to request a mode transition and
registers that report the status of the transition (for example,
MC_ME_MCTL to request mode transitions, MC_ME_IMTS to provide
the cause of an invalid mode interrupt, and MC_ME_DMTS to show the
status of the mode transition).
1
The monitoring and types of reactions can be enabled in the FCCU for the following fault inputs
:
• [SM_FMEDA_015]Compensation disable (FCCU ch 53)[end]
• [SM_FMEDA_016]SAFE mode (FCCU ch 52)[end]
1.See the “Module classification” table in the MPC5777M Reference Manual’s “Functional Safety” chapter for spe-
cific module safety classification.
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors12
Functional safety requirements for application software
3.2.4 Start-up configuration check
During boot, start-up software is not executed on the Safety Core.
Assumption: [SM_FMEDA_017]Safety software running on the Safety Core shall check correct
initialization of the MPC5777M before activating the safety-relevant functionality . This check shall not be
executed on the core executing the start-up software. [end]
3.2.5 Dual core lockstep mode
The MPC5777M device operates in delayed lockstep mode (LSM) to allow the highest safety level to be
reached. The Checker Core will receive all inputs delayed by two clock cycles. Outputs of the
Checker Core will be compared with outputs of the Master Core. Any differences will be flagged as an
error which will be processed by the FCCU.
For safety operation, the LOCKSTEP_EN bit in the flash memory UTEST miscellaneous DCF client must
not be set to disabled. If the LSM is disabled, the Checker Core and the Redundancy Checker Control
Units (RCCUs) are disabled. This triggers a fault indication to the FCCU. The Checker Core will not work
independently from the Master Core. No dynamic switching is possible between LSM on and LSM off
(any change to the LOCKSTEP_EN bit will only take effect after the next reset).
Before starting safety-relevant operations, the application software shall check that lockstep mode is
enabled (confirm MC_ME_CS[S_CORE1] = 1 (master) and MC_ME_CS[S_CORE2] = 1 (checker),
confirm that no failure is signalled on alarm #51, for example) and configure the FCCU to react to lockstep
disablement.
Assumption: [SCG18.027]Before starting safety-relevant operations, the application software shall check
that lockstep mode is enabled (for example, confirm MC_ME_CS[S_CORE1] = 1 (core_0, master) and
MC_ME_CS[S_CORE2] = 1 (core_0s, checker), and no failure is signalled on FCCU fault 51 (Lockstep
mode)), then configure the FCCU to react to lockstep disablement. [end]
3.2.6 FCCU fault reaction configuration
The Fault Collection and Control Unit (FCCU) collects faults and manages the reaction to these faults. A
mechanism is usually provided to allow software to check the integrity of the different error paths. Most
reactions are disabled at boot time so software configuration is required. Refer to Section 2.7, Failure
handling for the valid FCCU fault reactions.
Assumption: [SM_FMEDA_018]Application software shall check the FCCU configuration once after
programming. [end]
The FCCU is checked by the FCCU Output Supervision Unit (FOSU) which provides a secondary path
for the failure indication and reports to the Reset Generation Module (MC_RGM). The FOSU only causes
a reset if the FCCU fails to react to an enabled incoming enabled fault within a fixed time interval
(8000 IRCOSC cycles). The FOSU does not require software configuration. While the FCCU is in its
CONFIG state, the FOSU does not monitor the FCCU for faults or the resulting reaction.
Assumption: Application software shall check and clear any pending faults when it moves the FCCU out
of the CONFIG state.
NXP Semiconductors 13
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
Assumption: [SM_FMEDA_019] Before starting safety-relevant operations, software must configure the
fault reactions to each fault that is safety-relevant for the application. [end]
T o configure the fault reaction to each fault, the FCCU state machine is placed in the CONFIG state. Safety
analysis assumes that the CONFIG state of the FCCU is not a Safe state
MCU
.
To avoid a stuck condition in the CONFIG state due to a failure, the FCCU implements an internal
watchdog which, in case of a timeout condition, automatically transitions the FCCU state machine from
CONFIG to NORMAL state and restores default values of the configuration registers (see section “FCCU
CFG Timeout Register (FCCU_CFG_TO)” in the MPC5777M Reference Manual).
NOTE
Implementation hint: Software must program the FCCU configuration
registers (for example, FCCU_RFS_CFGn, FCCU_NMI_ENn,
FCCU_EOUT_SIG_ENn) to configure the fault reaction of each fault.
These registers are writable only if the FCCU is in the CONFIG state.
Assumption: [SM_FMEDA_020] The integrity of the entire error reaction path shall be verified at least
once after the boot. [end]
NOTE
Different approaches to verify the functionality of the error reaction paths
can be used. Some error reaction paths are checked during LBIST and don’t
require the development of additional software, whereas others require
application software.
The table “FCCU failure inputs” from in the “Functional Safety” chapter of
the MPC5777M Reference Manual shows the suggested approach for each
FCCU failure input.
The FCCU will come out of reset with most of the failure inputs disabled. Failures which occur during
boot will, for the most part, not be acknowledged by the FCCU as a failure. To check whether such errors
have occurred, SW can read the FCCU failure status registers for any latched error and act on the status of
those bits accordingly (FCCU_RF_S[0:3]).
NOTE
The MPC5777M Reference Manual’s “FCCU failure inputs” table in the
“Functional Safety” chapter lists failure sources, associated FCCU channels
and how they can be tested.
The error indication on pins, FI[0] and FI[1], are controlled by the SIUL2 and FCCU. The field
SIUL2_MSCR[SMC] can be configured to have the output buffer disabled when the MPC5777M enters
Safe mode (for example, for FI[0], SIUL2_MSCR27[SMC] = 0, and for FI[1],
SIUL2_MSCR34[SMC] = 0). The FCCU_CFG register is used to configure other FI[n] options like signal
polarity, switching mode, software control, and so on.
Assumption: [SM_FMEDA_124] It is assumed that whenever error indication is enabled on FI[n], the
SMC bit in associated MSCR register are always programmed to 1 with register access protection enabled.
[end]
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors14
Functional safety requirements for application software
The FCCU together with the INTC, can lead to cyclic reset. For example consider the following situation:
1. Error indication arrives at FCCU
2. FCCU triggers IRQ
3. SW analyzes fault and causes a reset
4. MCU comes out of reset and hands over to SW
5. SW configures INTC
6. SW gets the same IRQ again (because FCCU still holds the IRQ line), analyzes fault and causes a
reset ad infinitum (or rather till the reset escalator engages and causes a destructive reset).
To avoid this situation the following assumption is considered.
Assumption: [SCG18.500]It is assumed that FCCU pending fault status should be cleared before the
INTC is configured. [end]
Since the NMI is edge triggered, even if it is kept active during a functional reset until the fault status is
cleared, it will not interrupt the Safety Core and the described cyclic reset can't be seen.
Assumption: [SCG18.900]If the clock driving the FCCU (IRCOSC) fails, software must find other ways
to signal an error other than using the FCCU control of the error output pin(s) (FI[n]). [end]
NOTE
There are different methodologies that could be used to satisfy this
assumption. For example, issuing a reset, or switching FI[n] pin control to a
GPIO and using it to drive an error signal instead of using FI[n].
Assumption: [SCG18.901] If the FCCU uses NMI as a failure reaction, the Safety Core will not be
enabled after a reset during the first mode transition of the MC_ME module but earliest at the second
transition which will initiated earliest several IRCOSC cycles after the first. [end]
Unwanted activation of LBIST/MBIST causes a violation of the safety goal.
Assumption: [SM_FMEDA_028] Software shall always enable FCCU reactions to error events indicating
unexpected STCU2 activations. [end]
3.2.7 Reset Generation Module (MC_RGM)
The MC_RGM is the central point for resetting the MCU. One of its tasks is to prevent reset cycling caused
by reset escalation. It also can transition to SAFE mode. The SAFE mode has not been considered a Safe
state
Permanent cycling through otherwise safe states or permanent cycling between a safe state and an unsafe
state is considered a violation of the safety goal. Specifically, this scenario relates to a continuous
Reset – Start, Operation – Reset or Reset – Self-test – Reset sequence. Allowing such cycles would be
problematic as it would allow an unlimited number of attempts of the test that is causing the cycle which
could possibly endanger its ability to detect device failures.
during safety analysis.
MCU
To detect a loop of continuous functional resets, the MPC5777M supports functional reset escalation
which can be used to generate a destructive reset if the number of functional resets reaches the
programmed value. Once the functional reset escalation is enabled, the Reset Generation Module
NXP Semiconductors 15
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
(MC_RGM) increments a counter for each functional reset that occurs. When the number of functional
resets reaches the programmed value in the MC_RGM_FRET , the MC_RGM initiates a destructive reset.
The counter can be cleared by software, destructive reset or start-up reset.
A similar mechanism to detect a loop of continuous destructive resets is implemented in the MC_RGM.
When the destructive reset counter reaches the programmed value, the MCU will be held in reset until the
next power-on reset. The destructive reset counter can be cleared by software or by a power-on reset.
Assumption: [SCG18.028]Safety software will reset the functional and destructive reset counters every
time it has finished checking its environment (for example, before making the Fn pin active). [end] The
MC_RGM_FRET (functional reset counter) and MC_RGM_DRET (destructive reset counter) registers
allow the user to select the number of functional and destructive resets that can occur before action is taken
(see “Reset Generation Module (MC_RGM)” in the MPC5777M Reference Manual for details).
Assumption: [SM_FMEDA_022] Software shall enable functional reset escalation for the condition when
multiple functional resets occur consecutively. [end]
NOTE
Functional reset escalation is enabled by writing a non-zero value to the
MC_RGM_FRET register (see the MPC5777M Reference Manual’s ‘Reset
Generation Module (MC_RGM)).
Reset escalation is a hardware mechanism that provides protection against a loop of continuous resets. The
time between these loops can be so short that the application software doesn’t have time to take any action
to manage them. Longer reset cycles must be managed by application software.
Assumption: [SCG18.029]Before clearing the reset counters of the escalation mechanism, the safety
software shall ensure that longer reset cycles can be detected by the software. [end]
NOTE
There are various methods to implement this requirement. For example,
safety software, before clearing the reset counters, reads (and saves) the
FCCU error status indication (if any faults were found) and compares the
status with previous saved versions. If too many resets due to faults are
observed, software can react by triggering a destructive reset.
For some events, the MC_RGM can be configured to react not with a functional reset, but with a transition
to the SAFE mode (see the description of the MC_RGM_FEAR in the MPC5777M Reference Manual).
In such a case, one watchdog shall be kept enabled. If this watchdog times out, the FCCU shall move the
MCU into one of its safe states.
Assumption: [SCG18.030] If the MC_RGM is configured to react with a transition into SAFE mode, at
least one watchdog timer shall remain enabled. The FCCU shall be configured to react to a timeout of this
watchdog with a long functional reset or driving the error out signals to a fault condition. [end]
Assumption: [SM_FMEDA_023]Software will read the reset status after boot ensuring that the reset
cause is indicated. Then software will clear the register , and read back the value verifying that it is actually
cleared. [end]
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors16
Functional safety requirements for application software
Assumption: [SM_FMEDA_024]Resets during normal operation will be executed only as a reaction to
an error, not as a functional measure. This avoids undetected faults due to interrupts that are not being
generated. [end]
3.2.8 Self-test completion
To ensure absence of latent faults, the self-test executes both a Logic Built-In Self-Test (LBIST) and a
Memory Built-In Self-Test (MBIST) during boot while the device is still under reset (offline). The boot
time BIST includes the scan-based LBIST to test the digital logic and the MBIST to test all RAMs and
ROMs1.
NOTE
The overall control of LBISTs and MBISTs is provided by the Self-Test
Control Unit (STCU2). The STCU2 will execute automatically after a
power-on reset2 (POR), external reset and destructive reset, and will also
execute when initiated by software (online self-test). The MPC5777M logic
is grouped into ten LBIST partitions used for both production testing and
self-test.
The MPC5777M Reference Manual’s “Self-Test Control Unit (STCU2)”
chapter and “Use cases and limitations” section discusses details on how to
correctly execute offline and online self-tests.
The section “Online Logical BIST (LBIST)” of the MPC5777M Reference
Manual’s “Functional safety chapter” shows tables of the module groupings
of each LBIST partition.
Assumption: [SCG18.125]If there is an LBIST failure, or MBIST detects uncorrectable failures, the
STCU2 will cause a destructive reset, causing execution of the self-test again. This is to ensure that a
self-test, which fails only due to a transient error, will not block device usage. If several self-tests fail in a
row, the desctructive reset escalation will activate and hold the MCU in reset. [end]
On the other hand, if MBIST detects correctable failures, software must decide whether to continue or halt
execution. In fact, the MBIST may detect and report two (or more) Single Bit Errors (SBEs) occurring in
multiple test passes instead of one Multiple Bit Error (MBE).
Assumption: [SM_FMEDA_025] Software will determine if two or more errors reported by the MBIST
as SBEs combine to create an uncorrectable error by examining the entries in the System RAM Memory
Management Unit (MEMU) instance. If several entries exist for the same address with different bit numbers, this data word actually has an MBE instead of the several SBEs discovered by the MBIST. [end]
Assumption: [SM_FMEDA_026] After start up (and more in general, always after the execution of
MBIST s), software will cross check MBIST status in the STCU2 (pass or fail) with the content of MEMU
MBIST buffer (same as system RAM) to detect failures af fecting the reporting of MBIST errors. This can
1.This does not include flash memory.
2.The customer must enable the self-test in the shadow sector of the flash memory since the factory default configu-
ration will be to not run the self-test).
NXP Semiconductors 17
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
be due to faults affecting the reporting path for MEMU or STCU2 logic. (notice that STCU2 is not part of
any LBIST partition and only a pass/fail flag is available). [end]
Assumption: [SCG18.031]After start-up and before the safety application starts, application software
shall confirm that all LBIST s and MBISTs finished successfully, MISRs contain the expected values, and
no critical failure is flagged. The critical failures may include LBIST failures, MBIST MBEs, MBIST
SBEs exceeding the maximum tolerated number (<= 8 due to MEMU buffer size) and self-test failures.
[end]
NOTE
See the “Off-Line Self-T est Sequence” section in the MPC5777M Reference
Manual for details about test sequencing and completion validation.
The STCU2, as well as LBIST and MBIST controllers, are themselves subject to failures, which may
prevent self-tests from executing correctly (for example, no self-test execution, or execution of the wrong
algorithm). For latent faults affecting LBIST execution, checking the MISR register upon LBIST
completion is considered sufficient. For MBIST only a pass/fail flag is provided (besides the collection of
detected MBIST errors in the MEMU).
The following must be followed to improve the detection of latent faults, particularly those affecting
correct MBIST execution:
• Recommendation: LBIST should be scheduled before MBIST since LBIST s also cover the logic
running memory self-tests and the MEMU BIST error collection logic/buffers; this will help to
detect latent faults responsible for the wrong or incomplete execution of memory self tests or
wrong reporting of their results.
• Recommendation: The STCU2 CRC feature should be enabled to check that the signals
exchanged between the STCU2 and MBIST/LBIST controllers are correct (for example, STCU2
commands and LBIST/MBIST responses).
NOTE
The expected signature depends on the sequence of tests. Customers can
determine the expected signature by running the desired sequence of tests
and reading the resulting CRC upon test completion. One signature must be
computed for each test sequence (for example, one for the start-up test
sequence and one for each on-line test performed).
As far as the STCU2 error reaction path is concerned, the following are given:
• Assumption: [SM_FMEDA_027] SW will check the integrity of the STCU2 Unrecoverable
Fault/Recoverable Fault (UF/RF) error lines that signal the FCCU and the MC_RGM (UF only)
via the fake error injection register interface provided by STCU2. Before running the test, FCCU
and MC_RGM shall be configured in order not to cause undesired reaction. [end]
• Recommendation: During the execution of the safety function, and when no on-line self-test is
requested, software should disable the FCCU and MC_RGM reactions to STCU2 UF/RF error
indications to avoid false trip to the safe state or interference in case of unexpected error
indications.
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors18
Functional safety requirements for application software
The STCU2 provides a key-based mechanism to prevent unauthorized write accesses to its register
interface. The integrity of such protection mechanism can be checked by running the following test: [end]
• Assumption: [SM_FMEDA_029] SW shall perform a write access to one of the STCU2 registers
without providing the requested key pair and check for the generation of the expected transfer error .
[end]
The STCU2 allows execution of logic and memory BIST also during runtime upon a SW request. If the
I/O (including FI[n]) pins need a defined state during on-line LBIST, the following is recommended:
• Reset SIUL prior to on-line LBIST (using the MC_RGM_PRST0[SIUL_RST] field).
• Set pins to a desired state (if the reset-state does not meet requirements).
The following Assumptions have to be satisfied when the on-line BIST feature is used:
• [SM_FMEDA_030] SW shall verify that STCU2 configuration is correct before triggering the
execution of on-line BISTs. [end]
• [SM_FMEDA_031] STCU2 status has to be checked after the execution of on-line LBIST/MBIST
to verify that all scheduled tests have been executed and completed successfully. [end]
• [SM_FMEDA_032] Software shall supervise the execution time of on-line self tests using the
SWT or any other available timer. The internal STCU2 WDT might suffer from CCFs causing
either no, or slower, test execution. This may mean that no WDT timeout occurs (as internal WDT
and STCU2 core logic share the same clock). [end]
NOTE
During start-up, no safety function is executed and the start up time is
supervised by the external WDT. The internal prescaler feeding both the
STCU2 WDT and core logic can be checked by running an on-line test and
checking its execution time.
• [SM_FMEDA_033] On completion of the on-line LBIST software shall check whether reset was
correctly applied to the partition(s) under test. This can be done by checking one or more registers
(at least 2 recommended) for their expected reset value. T esting is not necessary if a global system
reset is applied at the end of the test. [end]
• [SM_FMEDA_034] On exiting from a functional reset, software will check the status of the
STCU2 to verify there are no running BISTs nor any hardware aborted tests. [end]
NOTE
BISTs still running after a functional reset are the result of incorrectly
handled hardware abort requests by the STCU2 that occurred while on-line
BISTs were executing.
• [SM_FMEDA_035] If STCU2 interrupt capabilities are used to notify end of test session
execution, application will handle the case of missing interrupt(s) (for example, by supervising test
execution time or periodically polling STCU2 status (checking STCU2_RUNSW[RUNSW], or
STCU2_INT_FLG[MBIFLG] (for MBIST) and STCU2_INT_FLG[LBIFLG] (for LBIST)). [end]
NXP Semiconductors 19
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
3.2.9 MEMU initial checks
MBISTs report detected faults to the same MEMU reporting block used for System RAM ECC failures.
Errors are in general distinguished between single-bit and multi-bit. However, it is not guaranteed that
single-bit errors found in different steps on the same address are reported as multi-bit errors
Recommendation: The application software can write known error addresses into the MEMU reporting
table to prevent reporting of those errors to the FCCU in case the addresses are accessed again.
3.2.10 Flash memory configuration and tests
MPC5777M provides 8.7 MB of programmable non-volatile (NVM) flash memory with ECC which can
be used for instruction and/or data storage.
Assumption: [SM_FMEDA_036]T o detect failures where a wrong or multiple selection targets a different
block while programming, application SW shall configure flash memory blocks as read only when not the
target of a write operation. [end]
NOTE
See the “Program software locking” section in the “Embedded Flash
Memory” chapter of the MPC5777M Reference Manual for details.
The flash memory array integrity self check detects possible latent faults affecting the flash memory array ,
including potential data integrity issues, or the logic involved in read operations (for example, sense
amplifiers, column mux’s, address decoder, voltage/timing references). It calculates a MISR signature
over the array content and thus validates the content of the array as well as the decoder logic. The
calculated MISR value is dependent on the array content and must be validated by software.
The array integrity MISR value is calculated after ECC detection and correction. Flash memory ECC logic
accounts for single-bit correction (SBC) opportunities, and will output corrected data into the MISR
calculation.
Single bit correction reporting still occurs in the FLASH_MCR[SBC] bit and the FLASH_ADR during AI
if FLASH_UT0[SBCE] = 1.
The AI breakpoint feature allows to break the Array Integrity Check execution if an event is a single bit
correction or a double bit detection. Array Integrity Check can be resumed by the application after
verifying the source of the correction/error and clearing the respective status bit (for example, MCR[SBC]
or MCR[EER]).
Assumption: [SCG18.032]The application software shall run the flash memory AI at start-up to detect
possible latent faults. [end]
NOTE
See the “Array Integrity Self Check” section in the MPC5777M Reference
Manual for details.
In the event of a user detected single-bit correction through user reads or an array integrity check, a margin
read may be done to check for a possible second bit failing within the selected margin levels.
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors20
Functional safety requirements for application software
Assumption: [SCG18.151] A margin read test should be executed after a new single-bit error correction
has occurred in flash memory . The mar gin read test does not need immediate execution, but it needs to be
run within the next few trip cycles. Multiple single-bit errors can be the first indications of a data retention
problem that could have the potential of causing multi-bit errors. [end] The MEMU can be used to store
the address of the location reporting the error event.
NOTE
Implementation hint: Refer to the MPC5777M Reference Manual’s “User
margin read” section of the “Embedded Flash Memory (c55fmc)” chapter
for details.
3.2.11 Voltage monitor configuration
To assist in maintaining functional safety, the Power Management Controller (PMC) monitors various
supply voltages of the MPC5777M device. The “POR and voltage monitors description” table in the
“Power management” chapter of the MPC5777M Reference Manual shows a detailed list of the LVDs and
HVDs embedded in the MPC5777M.
Apart from the self-test, the use of the PMC for ASIL D applications is transparent to the user because the
operation of the PMC is automatic (see SM_FMEDA_037 below, on page 21).
PMC failures primarily report to the MC_RGM. Since safety-relevant voltages have the potential to
disable the failure indication mechanisms of the MPC5777M (the FCCU and its error out signals), their
error indication directly causes a transition into a Safe state
by reset. Additionally, LVDs and HVDs
MCU
also report errors to the FCCU, but under the recommended configuration (MCU reset by MC_RGM
enabled) this is irrelevant.
Assumption: Software shall not disable the direct transition into a safe state due to an overvoltage or
undervoltage indication.
The customer can, at their own risk, disable the direct triggering of resets by the MC_RGM and rely on
the FCCU reactions to overvoltage and undervoltage, even when FCCU is configured for IRQs as the
reaction. In general, the FCCU reaction (clocked by the IRCOSC) will take more time than the MC_RGM
reaction (asynchronous). So, if the FCCU is to trigger an IRQ reaction, there is an increased probability
that a fast voltage drop could cause a brownout condition on the device before a reaction occurs. If IRQs
are selected as the FCCU reaction, there will be no guarantee that Diagnostic Coverage of overvoltage or
undervoltage will be properly detected, and the safety analysis (FMEDA) of the MCU, will not be valid
with respect to this failure mode.
To check the L VDs and HVDs for latent faults, which could im pact their ability to correctly trigger when
an undervoltage or overvoltage situation occurs, it is assumed there will be two software self-tests that will
be executed by during startup.
Assumption: [SM_FMEDA_037]Reference voltages, and input voltages of LVDs/HVDs, shall be
acquired using the ADC. The conversion values shall be compared with the expected ADC values. The
application software shall initiate the hardware assisted self-test to detect L VD/HVD failures after start-up.
[end]
NXP Semiconductors 21
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
NOTE
This is to check that the voltage supervised by the LVD/HVD is actually the
correct one and not influenced by opens or shorts in such a way that it never
could cross the LVD/HVD threshold. The LVDs/HVDs are monitored by
SARADC_B input channels 96 to 101 and 112 to 119(see the MPC5777M
Reference Manual’s “Analog-to-Digital Converters (ADC) Configuration”
chapter and the “SARADC_B analog test channel assignment” table for
details).
Assumption: [SM_FMEDA_150] Software shall initiate a self-test of LVD/HVD comparator. [end]
NOTE
This is to check that a L VD/HVD will trigger at approximately correct value
(see the MPC5777M Reference Manual’s “Power Management Controller
digital interface (PMC_dig)” chapter, section “Voltage Detect User Mode
T est Register (VD_UTST)”, and the “Device Configuration” chapter , “L VD
/ HVD self test” section, “LVD /HVD self test decoding” table).
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors22
Functional safety requirements for application software
To run the LVD/HVD self-test, application software shall execute the following steps:
1. Mask LVD/HVD by clearing the Reset Event Enable Register (PMC_REE_TD, PMC_REE_VDn
registers) of the PMC (see the "Power Management Controller digital interface (PMC_dig)"
chapter in the MPC5777M Reference Manual).
2. Clear LVD/HVD in Event Pending Register (PMC_REE_TD, PMC_REE_VDn).
3. Write the PMC_VD_UTST register to the desired LVD/HVD to test.
4. Enable VD_UTST bits in MCR (PMC_MCR) by setting USER_SELF_TEST_EN to start testing.
5. Verify test results by polling the Event Pending Registers (PMC_EPR_VDn or PMC_EPR_TD)
flag:
a) If the flag is set, the LVD (or HVD) test passed as expected.
b) If the flag is not set, self-test failed.
NOTE
Software may configure a timeout period to be sure the flag asserts within a
specified time (this time shall be greater than 20 μs).
6. Disable the VD_UTST bits in MCR (PMC_MCR) by clearing the USER_SELF_TEST_EN to end
the test.
7. Clear PMC_VD_UTST.
8. Clear the L VD (or HVD) flag in the Event Pending Register (PMC_EPR_TD or PMC_EPR_VDn).
9. Wait for the PMC_GR_S bit to be de-asserted.
NOTE
Software may configure a timeout period to be sure the flag or flags clear
within a specified time.
10. Enable the LVD (or HVD) by setting the appropriate field in the Reset Event Enable Register
(PMC_REE_TD or PMC_REE_VDn).
These steps shall be repeated for each LVD (or HVD) to be tested. See the following sections of the
MPC5777M Reference Manual:
• “Power Management Controller digital interface (PMC_dig)” chapter, “Voltage Detect User Mode
Test Register (VD_UTST)” section
• “Device Configuration” chapter, “LVD / HVD self test” section
3.2.12 Temperature monitoring configuration
The MPC5777M supports a temperature sensor to detect over-temperature conditions. The temperature
sensor can be configured to provide an analog measurement of the temperature using SARB input channel
120.
To set a proper threshold the customer must consider the maximum operating junction temperature (see
the MPC5777M Data Sheet for the temperature sensor accuracy and maximum junction temperatures).
NXP Semiconductors 23
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
3.2.13 Clock monitoring configuration
Clocks are supervised by the Clock Monitoring Units (CMUs). The CMUs are driven by the 16 MHz
internal reference clock oscillator (IRCOSC) to ensure independence from the monitored clocks. The
CMUs flag errors associated with conditions due to clocks being out of programmable bounds, and loss of
reference clock. If a supervised clock leaves the specified range for the device, an error signal is sent to
the FCCU. MPC5777M includes the CMUs as shown in the “Clocking” chapter of the MPC5777M
Reference Manual. It is the responsibility of the software to verify that the IRCOSC and XOSC are valid
before starting the CMUs.
Assumption: [SM_FMEDA_040]The CMU frequency thresholds shall be configured for high and low
limits which are used to compare with the MCU operating frequency. [end]
Assumption: [SCG18.035]The potential exactness (or the required inexactness) of the CMU thresholds
shall be taken into account for both the IRCOSC and clock, or clocks, being monitored. [end]
NOTE
Implementation hint: For example, for the upper threshold customer
should target CLKnominal_freq + CLKacc% and convert it into the number
of IRC cycles in the worst case (slowest possible IRCOSC), for example
IRC_freq = IRCnominal_freq – IRCacc%. The opposite applies to the
lower threshold.
Assumption: [SM_FMEDA_041] For ASIL D applications, the use of the CMUs is mandatory. If the
related modules are used by the application safety function, the user shall verify that the CMUs are not
disabled and their faults are managed by the FCCU. The FCCU’s default configuration does not manage
the CMU faults, so it shall be configured accordingly. [end]
Assumption: [SM_FMEDA_042]Application software shall check the configuration of the CMU once
after programming. [end]
Assumption: [SM_FMEDA_043]Once after the boot the application shall measure the CLKMT0_RMN
frequency (IRCOSC) with CLKMN0_RMT (XOSC) as reference clock exploiting the CMU frequency
measurement feature. To detect failure of the IRCOSC, the application software shall utilize the CMU’s
frequency meter to read the IRCOSC frequency and compare it against the expected value of 16
1
[end]
MHz
Assumption: [SM_FMEDA_044]After start-up, the CMU reaction path shall be tested by modifying the
CMU threshold. [end]
Assumption: [SM_FMEDA_045]To detect delays in clock mode switching and lost clock switching, the
software shall ensure the CMU is reprogrammed with the new expected clock frequency minimum and
maximum values within the FTTI. [end]
1. Nominal frequency of the IRCOSC is 16 MHz, but a post trim accuracy over voltage and temperature must be taken into
account (see the ‘Internal RC Oscillator electrical specifications’ in the MPC5777M Data Sheet).
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors24
Functional safety requirements for application software
NOTE
The frequency range of the CMU must be increased before switching clock
modes. The requirement is to program the CMU with the correct minimum
and maximum values for the new frequency soon after the switch.
Recommendation: The application may run the IOSC_A001_SW (on page 24) once per FTTI to verify
proper IRCOSC operation.
3.2.14 System clock availability
At start-up, the CMUs are not initialized and the IRCOSC is the default system clock. Stuck-at faults on
the external oscillator (XOSC) are not detected by the CMUs at start-up since the monitoring units are not
initialized and the MPC5777M is still running on the IRCOSC.
Assumption: [SM_FMEDA_047]The software shall verify that the clocks are valid by checking the state
of the following:[end]
1. MC_ME_GS[S_XOSC] = 1, verifies valid XOSC
2. MC_ME_GS[S_IRC] = 1, verifies valid IRCOSC
3. The quality of the IRCOSC frequency is determined by clock metering and measuring the IRCOSC
against the XOSC (see the MPC5777M Reference Manual’s “Clock Monitoring Unit (CMU)”
chapter for details)
4. Based on measurement from 3, software shall update the user trim bits of the internal oscillator
(IRCOSC_CTL[USER_TRIM]).
5. Enable CMUs since we have valid XOSC and IRCOSC
6. MC_ME_GS[S_PLL0] = 1 and MC_ME_GS[S_PLL1] = 1, verifies valid PLL0 and PLL1 outputs
Assumption: [SM_FMEDA_048] Software shall check that the system clock is available, and sourced by
the FMPLL (PLL1), before running any safety element function or setting the FCCU into the operational
state. [end]
3.2.15 Clock Generation Module (MC_CGM)
The CMUs are the main mechanism used to check the integrity of MCU clocks, but other indirect measures
like delayed lockstep, fault tolerant communication protocols and replicated usage of peripherals may also
be used. The following assumptions are necessary to cover the clock failures that escape these safety
mechanisms which can potentially lead to the failure of specific modules.
Assumption: [SM_FMEDA_049]The sample time for the SARADC will be at least one clock cycle
longer than the minimum time required. This avoids clock glitches on the SAR clock from affecting
sampling. [end]
Assumption: [SM_FMEDA_050]Detecting failures of either CLKOUT0 or CLKOUT1 is the sole
responsibility of user application software. [end]
Assumption: [SM_FMEDA_051]To detect PSI5 reception failures due to a clock glitch, PSI5 will use the
three bit CRC included in the protocol. [end]
NXP Semiconductors 25
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
3.2.16 PLL generated clocking
MPC5777M provides dual PLLs (PLL0 and PLL1) for separate system and peripheral clocks.
[SCG18.145]Each PLL provides a glitch-free and fast clock to the MPC5777M and provides a loss of lock
signal that is routed to the FCCU. [end]
To reduce the impact of glitches stemming from the XOSC, the FMPLL (PLL1) should be used as the
system clock.
Assumption: [SM_FMEDA_052] Application software shall ensure that the system is using the FMPLL
(PLL1) clock as the system clock before running any safety functions, or before the FCCU indicates a
system that is functioning correctly (for example, on FI[n]). [end]
Assumption: [SM_FMEDA_053] Application shall configure the FCCU to react to both PLL loss of
locks. [end]
Both FlexRay and CAN feature modes in which they are directly clocked from the XOSC. For applications
targeting ASIL D, using these clocking modes increases the risk of a communication failures.
Assumption: [SM_FMEDA_054] Application software will not use FlexRay or CAN modules directly
clocked by the XOSC, or the used fault-tolerant communication layer will be capable of handling failures
induced by clock glitches (for example, timing errors, sampling errors and complete failure of logic due
to setup/hold time violations). [end]
3.2.17 XBAR configuration
The multi-port XBAR switch allows for concurrent transactions from any master (cores, DMA, FlexRay)
to any slave (memories, peripheral bridge). The XBAR module includes a set of configuration registers
for arbitration parameters, including priority , parking and arbitration algorithm. Faults in the configuration
registers affect slave arbitration so software countermeasures must detect these faults.
Assumption: [SCG18.042]Masters of the XBAR which are not ViMos or SuMos shall have a lower
arbitration priority on the XBAR than safety-relevant masters. [end]
Assumption: [SM_FMEDA_055] In cases where it is not possible to set the XBAR arbitration
appropriately, a failure probability shall be estimated for such cases. An example case is when FlexRay,
which is a PeMo, needs highest priority. [end]
Assumption: [SM_FMEDA_056] To prevent spurious XBAR accesses by the HSM to stall or delay the
safety function, the XBAR will be configured assigning low priority to the HSM. [end]
XBAR data and address lines are covered by E2E ECC. Some failures, particularly those affecting muxing
logic, might introduce multi-bit errors on data and addresses. Though ECC coverage is limited on a single
transaction the probability of detecting the fault is higher when multiple transactions are affected.
3.2.18 Platform flash memory controller
PFLASH controller configuration controls aspects related to flash memory remapping. It can remap
logical flash accesses to on-chip calibration RAM, extended off-chip calibration RAM or on-chip system
RAM.
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors26
Functional safety requirements for application software
Assumption: [SM_FMEDA_059]T o avoid incorrect remapping due to non-initialized remap descriptors,
unused PFLASH remap descriptors shall be initialized to an unused logical address[end].
NOTE
Remapped PFLASH regions are initialized by configuring
PFLASHC_PFCRDE and PFLASHC_PFCRDn registers.
If flash memory remapping is used during safety-relevant application execution, safe calibration needs to
be enabled via PFCRCR[SAFE_CAL]. After reset, calibration overlay regions are considered to be
safety-relevant (PFCRCR[SAFE_CAL] = 0, see section “e2eECC and Calibration Accesses” of chapter
“e2eECC and Calibration Accesses” in the MPC5777M Reference Manual for details).
3.2.19 Wake-Up Unit (WKPU) / External NMI
Assumption: [SM_FMEDA_167] NMI will only be used for error notifications or other uses where all
dangerous failures are latent failures.
Assumption: [SM_FMEDA_168] Application shall check the WKPU configuration and its functionality
at once after the boot. [end]
NOTE
The configuration can be verified by reading the configuration registers and
comparing them with the expected values.
Functionality can be tested by triggering the external NMI and check for the
expected reaction. Reset request to the MC_RGM can be reconfigured to
generate a SAFE mode or interrupt request.
3.2.20 Cache
Assumption: [SM_FMEDA_130] ECC/EDC protection of caches is assumed to be enabled (setting of the
Data Cache Error Checking Enable field in the L1 Cache Control and Status Register 0,
L1CSR0[DCECE] = 1). It is also assumed that ECC/EDC errors are handled by correction and
invalidation.
Handling ECC/EDC errors by a machine check is also possible if the machine check handler initiates
appropriate SW countermeasures (to achieve the former, L1CSR0[DCEA] = 01b). The handling of the
errors is assumed to occur as soon as the caches are enabled (see “Core Complex Overview” and
“e200z425Bn3 Core Description” chapters in the MPC5777M Reference Manual). [end]
3.2.21 Software Watchdog Timer (SWT)
Assumption: [SM_FMEDA_104] These requirements apply to the SWT for ASIL D applications: [end]
• The SWT shall be enabled and configuration registers have to be protected against undesired
accesses using one or more hardware mechanism implemented (for example, SMPU,
REG_PROT).
NXP Semiconductors 27
Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
• The SWT time window settings shall be set to a value less than the FTTI. Detection latency shall
be smaller than the FTTI.
• Before the safety function is executed, the software shall verify that the SWT is enabled by reading
the SWT control register (SWT_CR).
3.2.22 Analog to Digital Converters
MPC5777M includes both SD and SAR ADCs. One of the SAR ADCs is considered the supervisor, or
monitor, ADC (for example, SAR ADCB). The others ADCs have normal functionality.
The basic idea to verify the integrity of the functional ADCs is to implement software redundancy. This
redundancy is supported by hardware allowing acquisition of analog inputs using independent ADC
modules1.
Figure 1 shows the block scheme of connection of the SAR ADCs, including the supervisor. Through a
second level of multiplexing, all analog inputs connected to the functional ADCs (both SD and SAR), are
connected to the supervisor ADC.
1.Simultaneous sampling of two ADCs on the same analog input is not allowed (see the MPC5777M Reference Man-
ual for details).
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors28
Functional safety requirements for application software
Input mux
analog switch
pad cells
ADC Bandgap
Temp Sensor
IRC Reference
PMC Signals
Sigma-Delta
ADC inputs
2nd
Level
SoC
Mux
SAR ADCB
SAR ADC3
SAR ADC2
SAR ADC1
SAR ADC0
Bias
Generator
Figure 1. Block scheme of the SAR ADCs, including the supervisor ADC
The supervisor ADC can be a source of latent failures. T o detect these latent failures, before it can be used
to verify the behavior of functional ADCs, a test shall be executed once after the boot.
Assumption: [SM_FMEDA_153]T o detect latent failures, the supervisor ADC shall acquire some known
internal analog voltages and compare them with the expected values before the supervisor ADC can be
used for monitoring the functional ADCs. [end]
Values which must be acquired are:
• [SM_FMEDA_154]Bandgap ADC measurement. [end]
• Internal analog voltages listed in section “Internal reference” of the “Analog-to-Digital Converters
(ADC) Configuration” chapter of the MPC5777M Reference Manual.
A similar procedure shall be applied on the functional ADCs that will be used for acquiring safety relevant
data as described hereafter.
NXP Semiconductors 29
Safety Manual for MPC5777M, Rev. 1.1
Loading...