SPRACC0A November 2017 – November 2020 TMS320F28075 , TMS320F28075-Q1 , TMS320F28076 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28375S-Q1 , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377D-EP , TMS320F28377D-Q1 , TMS320F28377S , TMS320F28377S-Q1 , TMS320F28378D , TMS320F28378S , TMS320F28379D , TMS320F28379D-Q1
In-system testing involves testing a targeted circuit while the system is in full operation. This involves taking a time slice for the CPU’s attention to test a portion of the circuitry. This time slice must be small enough to not affect the CPU’s system responsibility. In a real-time control system this can be restrictive. With respect to the Safe State perspective, the complete range of the SRAM must be tested within each safety interval.
In-system testing of SRAM involves:
This has to be done before the system requires access to the SRAM under test. It is difficult to do this for a full SRAM instance within a device. However, it is possible to do this on a small slice of SRAM at a time, for example 16 or 32 words. As stated in Section 3.1.1, most defect related failures in-system can be detected with a simple March algorithm (March13n or even March7). In newer process nodes (45 nm and smaller), there is a need for more advanced algorithms to get the same coverage.
This method does not detect a failure on a system read of the SRAM, but can catch errors developing in the memory before the system reads a failing location. The method is used in cases where the SRAM in devices has no other detection methods available.