SPC56EL60 is a 32-bit system-on-chip (SoC) automotive microcontroller designed for
safety applications with a focus to minimize software measures within the CPU core
subsystem.
In order to reach this state, several software measures are required during the MCU poweron start-up procedure. This application note describes the software measures that user
must perform after the boot in order to detect and manage latent faults.
This document is valid only under the assumption that the MCU is used in locked step for
automotive applications with fail-silent or fail-indicate micros.
This application note is based on AN3077 rev. 2 (see B.1: Reference documents).
All the topics covered in this document also refer to RM0032 rev. 5, SPC56EL60L3,
SPC56EL60L5 datasheet rev. 5 and AN3121 rev. 1 (see B.1: Reference documents in
Appendix B).
This application note applies to SPC56EL60 devices according to Ta bl e 1 .
The Safety Application Guide (SAG) (please refer to AN3077, see B.1: Reference
documents in Appendix B) is the reference document to use.
This application note is focused to describe the individual software measures.
The SAG describes which measure to apply according to the application and peripheral
usage.
The hints that are described in this document should be considered as proposals to
implement the requirements described in SPC56EL60 SAG. Based on their applications
and the SAG, user can decide to use different implementations.
Doc ID 18311 Rev 16/37
AN3324How to implement power-on self test features
2 How to implement power-on self test features
The goal of this application note is to show how users can implement properly the safety
initialization and the self tests to allow to detect latent fault
(a)
and to manage them.
2.1 MCU initialization
At power-on, after register initialization (see Section 3.3: Redundancy Control Checker Unit
(RCCU)) and other basic initializations (MMU configuration, stack initialization, etc.) (see
Appendix A: CPU core initialization) user software has to verify if MCU is in alarm state or in
safe mode (coming from a Reset Condition) (see Section B.1: Reference documents in
Appendix B) and in that case must manage fault causes.
If current mode in Mode Entry module is default run mode (DRUN), software can proceed
with the default safety MCU initialization with self test features (see Figure 1: Initialization
flow).
Note:User can verify alarm state by reading Non Critical Fault on FCCU while he can verify safe
mode by reading Current Mode field (GS register) on Mode Entry module.
a. Latent fault: multiple point fault whose presence is not detected by a safety mechanism nor perceived by the
driver within the multiple point fault detection interval.
Doc ID 18311 Rev 17/37
AN3324How to implement power-on self test features
Figure 1.Initialization flow
Reset
CPU Core
Initialization
Read Non Critical
Faults
FCCU in
Safe State or Alarm
State
2.1.1 Safety initialization
Figure 2 shows an example of how to implement a safety initialization (see Section 3:
Module software requirements for non applicative peripherals).
User should take care that:
1. Execution order is not mandatory but it is strongly recommended (see Figure 2: Safety
initialization flow).
2. SWT (Software Watchdog Timer) is enabled.
3. RGM (Re set Generation Module) and FCCU (Fault Collection and Control Unit) must
be configured before all monitors or detectors are initialized.
Yes
Fault Manager
NO
MCU
Initialization
Check Faults
User Code
Doc ID 18311 Rev 18/37
AN3324How to implement power-on self test features
Figure 2.Safety initialization flow
Begin
Disable SWT
Enable All
Peripherals
Init FCCU
Init RGM
Init Magic Carpet
(ME-Clocks-FMPLL-Wait States)
Inhibit BAM
Execution
Configure CMU
Init Peripheral
Bridge
Init and Enable
IRQ Management
End
Doc ID 18311 Rev 19/37
AN3324How to implement power-on self test features
2.2 Safety verification and faults checking
At the end of safety initialization, user software has to verify some basic safety requirements
and verify if there is any fault (see Section 3: Module software requirements for non
applicative peripherals). Figure 3 shows an example of how to implement the faults check
flow.
Doc ID 18311 Rev 110/37
AN3324How to implement power-on self test features
Figure 3.Faults check flow
Begin
NO
NO
NO
NO
NO
MCU in
Lock Step
YES
Flash Array Integrity
Check
YES
STCU Check
YES
PMU Check
YES
IRC Check
YES
NO
NO
Fault Manager
Temperature Check
YES
Configure SWT
SWT Check
YES
End
Doc ID 18311 Rev 111/37
AN3324Module software requirements for non applicative peripherals
3 Module software requirements for non applicative
peripherals
This chapter describes the requirements of the software modules that should check the
system peripherals and the Flash. The checks are required for any application.
The peripherals treated in this chapter are accounted as non applicable peripherals
because they are not involved directly in any application Safety Integrity Function (SIF)
please refer to AN3077 (see B.1: Reference documents in Appendix B).
3.1 System Status and Configuration Module (SSCM)
Before executing safety functions, user must perform two actions:
1.Configure the SSCM to inhibit unintentional execution of the BAM code.
Note:This requirement is satisfied by asserting the flag PAE in the ERROR register of the SSCM.
Each access to the BAM memory area produces a Prefetch or Abort exception.
2. Verify that the device operates in Lock-Step Mode (LSM).
Note:Software needs to check this condition by reading the LSM flag in the System Status
Register (SSCM_STATUS) and verifying that the device is operated in the intended mode of
operation.
3.2 Self Test Control Unit (STCU)
After boot, user software must check the STCU to ensure its reliability. The software must
perform several operations based on the STCU status conditions after the power-on self
test. Even if no errors are reported, user software should confirm that the expected and
actual values within the CRC (Cyclic Redundancy Check) and LBIST MISR registers do not
indicate an error.
This software confirmation prevents a fault within the STCU itself incorrectly indicating that
the self test passed.
In the case of no reported errors, user softwareshould confirm that:
1.The internal CRC computation result matches the expected value.
Note:Read the CRCE and CRCR registers to check the coherency with the STCU_ERR[CRCS]
flag.
2. The signature registers of each of the LBIST results match their corresponding
expected values.
Note:For each LBIST, read the STCU_LBMISREL/H and STCU_LBIST_NMISRRL/H registers to
check the coherency with the STCU_LBS bits.
3. Read the registers used for Reported Errors and verify that their values are as
expected. Refer to the “Integrity SW operations” section in RM0032 (see B.1:
Reference documents in Appendix B).
Note:Verify that STCU_LBS, STCU_LBE, STCU_MBSL, STCU_MBEL flag registers values are
as expected. (LBIST and MBIST finished with success).
Doc ID 18311 Rev 112/37
Loading...
+ 25 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.