Safety Manual for MPC5777M, Rev. 1.1
Functional safety requirements for application software
NXP Semiconductors32
The result of the runtime computation is then compared to the offline one.
CMU registers are sources of latent failures which cannot lead directly to the violation of the safety goal.
The assumption below shall be considered.
Assumption: [SCG18.099]To reduce number of possible CCFs, the configuration registers of the
CMU_1, used to monitor the clock source of the Safety Core, shall be included into the periodic register
CRCing scheme. [end]
Assumption: [SCG18.040]The two CRC units are not specifically designed to be used redundantly (for
example, to check each other). In fact, there is no dependency constraint imposed on the design. [end]
3.3.3 XBAR usage
The application software must check the XBAR configuration once after programming but it must also
detect failures of the XBAR when safety-relevant functions are running.
Assumption: [SCG18.055] Application software shall check the configuration of XBAR every FTTI to
detect failures affecting the register interface. [end]
Assumption: [SCG18.056]Within the FTTI, application software will detect failures of the XBAR con-
figuration affecting system performance. [end]
The detection of failures of the XBAR configuration can be achieved as a combination of periodic
read-back of the configuration registers and control flow monitoring using the SWT. The SWT is needed
to cover those failure conditions leading to a complete lock-out of XBAR masters. The need for periodic
configuration read-back depends on how stringent the control flow monitoring is implemented.
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.
Assumption: [SM_FMEDA_063]Safety analysis assumes that at least two transactions are affected (for
example, at least two accesses are made by or to the safety relevant XBAR master(s) or slave(s) within
each FTTI). [end]
3.3.4 System Memory Protection Unit (SMPU)
The SMPU provides memory protection at the XBAR. A failure in the SMPU can change the behavior of
the SMPU (for example, enabling or disabling the protection), resulting in unauthorized access to the
protected data, or leading to unexpected access violations and data storage exceptions.
The protection against such failures is given by the read-back of the configuration registers, together with
the exception handler and the SWT if the exception handler cannot execute. SWT and exception handlers
are assumed to cover cases when accesses to system resources are unexpectedly prevented to authorized
masters. On the other hand, SMPU failures resulting in missing memory protection are considered critical
only if coupled with other failures causing the undesired access to protected data (notice that systematic
failures, besides random HW failures, can lead to this scenario).
To Next Page
Loading...
Need help?
General
