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
Testing the SRAM at start-up does not address the three above listed perspectives. However, there is significant value added in testing the SRAM at start-up even if it is not possible to test while the system is operational.
There is a proverb in the semiconductor industry that the second worst thing you can do to a system is power it down, with the very worst thing being power up. This is because the voltage and current swings during power up and power down of a system (or system component) cannot be fully managed. The devices are designed to work with this, but should a destructive power event occur, it is more likely to occur during power up/down. Therefore, testing the SRAM at power up addresses the most likely points where the circuit will be damaged.
Additionally, SRAM is easier to test at start up because there is no context to save and restore because the system context has not yet been loaded. SRAM testing by the embedded CPU takes a lot of CPU cycles and is not as easily or as effectively done while sharing the CPU resources with the system operation.