Hello Simon!
Please find the answers to your questions below.
-Regards,
Ehtesham
Hi!
It is unclear for us how to interpret the result of the worksheet S32K324.CUT_1_0.RELEASE.2021_R2.002-257pins.xslx which shows Transient and Combined Fault Metric at about 81%, but this should be above 90% to meet ASIL-B requirements? What is the background for this low value and can we expect this to impact the design/safety concept in any way moving ahead? Is this equally valid for the S32K312?
[EK] - The diagnostic coverage for the M7_TCM by the ECC was mistakenly entered 0% instead of 99%. Due to which the transient and combined fault metric was less than the required for ASIL-B. It has been rectified and is updated in the Safeassure.
It is unclear for us how to interpret the necessity of off-chip safety mechanisms based on the provided safety manual, S32K3XXSM_Rev_1.pdf, for instance the SM3.FCCU_MON is described as an assumption in the safety manual, with no ASIL dependency, however the FS26 comes in ASIL-B tagged variants without this feature whereas the FS86 does not. To minimize risk, we would like to understand the criticality of all the SM3.XXXXX safety mechanisms in more detail, so we can be confident in our power supply design choice moving ahead. Also which voltage levels are necessary to monitor. In the safety manual only VDD_HV_A/B and V15, the logic supply, is mentioned. Is there no requirement to monitor the core and flash voltage?
[EK] -The SM3.FCCU_MON is used to cover latent faults of FCCU fault indication signals and provides coverage over the FCCU pins. So irrespective of whether you are using the SBC or not, NXP recommends that you should test this interface before starting your safety application. Depending upon how you are using these signals in your system, you can think of alternate ways to test this path.
SM3.PWR_MON: The core and flash voltages are internally generated from the VDD_HV_A/B and V15 power supplies and are also monitored internally. So only external supplies VDD_HV_A/B, V15 need to be monitored.
SM3.EXT_WDG is used as safety mechanisms to detect failures of MCU due to common-cause failures (RGM, Power supplies).
SM3.RESET_MON is used to detect reset cycling. As per the assumed concept, it is assumed that the system enter safe state when MCU asserts its reset. But in case of reset cycling, as well we recommend to enter safe-state.
Hope this explains the purpose of the SM3 safety mechanisms and enables you to think of measures in your system safety concept that can detect these failures.
We are also wondering why the spread-sheet states 0% diagnostic coverage for M7_TCM (TCM RAM memory)? This memory should have ECC, what else is needed for coverage?
[EK] - Discussed in question 1
Finally, as we understand it we will have to implement our own diagnostic functions for any peripheral that we use (SPI for example).
Is anything provided by the HW to get coverage, like parity check on configuration memory and does NXP provide any diagnostic SW library to get diagnostic coverage for the peripherals?
[EK] - There are some safety mechanisms available for some of the chip peripherals. These are as follows:
-FlexCAN internal memories are protected by ECC implementing SECDED (SM1.DATA_ECC).
-EMAC implements data-path parity protection, master and slave interface timeouts, and finite-state-machine register parity protection and timeout. Memories associated with EMAC are protected by ECC implementing SECDED (SM1.DATA_ECC). Error injection for these safety mechanisms of EMAC is supported and these mechanisms can be tested by sCheck safety mechanism which is executable during start-up and shutdown.
For the other peripherals, you will have to implement your own diagnostic functions to achieve the desired diagnostic coverage as per the application ASIL. The safety manual provides some guidelines for the system developers for the safe usage of chip peripherals.
