SFFS222 October 2023 TMS320F2800153-Q1 , TMS320F2800154-Q1 , TMS320F2800155-Q1 , TMS320F2800156-Q1 , TMS320F2800157 , TMS320F2800157-Q1
This section provides the high level details related to what a system integrator must consider during the process of defining and building their F280015x based safety architecture.
The software support for the various safety mechanisms in the F280015x can be divided into the following categories:
A safe product built on the F280015x device hierarchically deploys each of the software solutions provided by TI. The first in the hierarchy is the C28x_STL which detect permanent faults inside the CPU by implementing the CPU3 - Software Test of CPU safety mechanism. The second in the hierarchy is the SDL which provides a series of examples of safety mechanisms that are designed to detect permanent faults inside several key elements within the F280015x device.
Since other safety mechanisms make use of and depend on the C28x CPU, it is important to run the C28x_STL first to make sure that the CPU is functioning properly and is capable of performing the required safety operations. Additionally, to detect potential causes of failure of the C28x_STL, the integrator should make sure that the internal watchdog, the LCM, and the Flash and RAM ECC/Parity logic are enabled before the C28x_STL runs.
The SDL supports safety mechanisms such as: CPU22 - Self-test Logic for LCM, CLK10 - Software Test of Watchdog (WD) Operation, CLK12 - Software Test of Missing Clock Detect Functionality, SRAM14 - Software Test of Parity Logic, SRAM13 - Software Test of ECC Logic, SRAM3 - Software Test of SRAM and several other key processing elements. The system integrator must study all the safety mechanisms and determine their applicability into the safety system being designed. The safety system must be evaluated with respect to the startup and runtime constraints and whether the software diagnostic tests can be run during POST, PEST or a combination of both.