DocID024464

Rev 2

9/27

AN4287

Functional safety requirements for application software

3.5

FLASH Memory

Suggested: FLASH memory is protected by a single error correction/dual error detection

(SEC/DED) ECC scheme. The SEC/DED ECC scheme reporting shall be configured

(interrupt request). The FLASH memory SEC/DED concerns data and not the addresses.

These specific software countermeasures can run once after the Power-On Reset (POR)

before running the SIF.

Suggested: in order to increase the diagnostic coverage, specific software

countermeasures shall be implemented to detect FLASH memory address logic faults.

These specific software countermeasures can run once per FTTI.

Rationale: to verify the integrity of FLASH memory address logic.

Implementation hint: e.g. known pattern can be read.

Suggested: in order to increase the diagnostic coverage, specific software

countermeasures shall be implemented to detect FLASH ECC logic faults. The aim is to

assure that correct data are not accidentally modified and that single bit errors are rightly

corrected. These specific software countermeasures can run once per FTTI.

Rationale: to verify the integrity of FLASH ECC logic.

Implementation hint: see Chapter 5: ECC logic test for further details.

Suggested: in order to increase the diagnostic coverage, an MBIST algorithms shall be

implemented to protect the system FLASH memory against hardware dormant faults. The

implemented MBIST algorithms can run once after the Power-On Reset (POR).

Rationale: to check the integrity of the FLASH memory.

Implementation hint: hardware support test called Array Integrity Self Check can be used

(refer to the SPC564A7x/SPC564A80 Reference Manual to have all additional details).

Suggested: in order to check the correctness of the writing process, written data shall be

read-back and compared with the intended ones. These specific software countermeasures

can run once after every write operation or after a series of write operations.

Rationale: to verify that written data are coherent with the intended ones.

3.6

Interrupt Controller (INTC)

Suggested: integrity of the INTC module shall be checked. These specific software

countermeasures can run once after the Power-On Reset (POR) before running the SIF.

Implementation hint: e.g. the INTC module is configured to generate some interrupt

requests and the expected behavior is verified.

Suggested: considering that no specific hardware protection is implemented against

failures in the Interrupt Controller, spurious/missing interrupt requests caused by

Electromagnetic Interference (EMI) or by bit flips in the interrupt registers of the peripherals,

applications not resilient against such errors shall include detection or protection software

countermeasures. These specific software countermeasures can run for each interrupt

request.

Rationale: to verify interrupt requests are serviced correctly.

Implementation hint: e.g. spurious interrupts can be detected checking corresponding

interrupt status in the interrupt status register of the related peripheral before executing the