TMS570LS3137: The method of fault injection test

So (1) is just logic that counts ECC errors and tracks

Maybe you are actually asking about 7.119 'Software Test of ECC Profiler'. ?

For (2) aren't the tests listed in the column 'Possible Tests for Diagnostics' the ones that you might run in order to stimulate this path..

Hello Anthony.
Thank you for reply.

>Maybe you are actually asking about 7.119 'Software Test of ECC Profiler'. ?
It is slightly different.
I think this test is confirm to mechanism "Primary SRAM Correctable ECC Profiling",but not fault injection to "Primary SRAM Correctable ECC Profiling". What do you think?

For (2) is I understood.Thank you.
Safety mechanism that fault injection test can not be realized, are not necessary to do.

Best Regards

Arriy,

As Anthony mentioned, the diagnostic "Primary SRAM Correctable ECC Profiling" is used to monitor ECC events. This is used in some cases to detect a high number of correctable errors which indicates operation in an environment that is subjecting the MCU to increased risk (high radiation of other influence on RAM bit integrity). Applications that monitor this metric, might use this count to put the device into a safe state until the corruption resides or until the next power cycle dependent on the application requirements.

From a test of diagnostic point of view, it is not possible to insert a fault into the ECC profiling logic at the device level. It can only be done during simulation on the code used to generate the chip which is what we have done for our FIT rate calculation models. For latent fault detection in the logic, we use teh SW test of function diagnostic to test that the ECC profiling is working as planned. This is done by creating a memory location with a single bit error, reading it, and verifying that the profiling count increments. This can be done on a startup (boot time) or periodic basis dependent on application throughput needs.

For the ESM software test of error path, it is again a proof of function test to insure the logic paths between the fault detection mechanism and the fault communication mechanism (ESM) is in tact and functioning. It is not possible to create a fault in the path to test for failure given failure is simply that the error notification in the ESM will not happen. The more prudent test is to confirm that the path is working as intended and no other errors are seen other than the error that is intended. These tests can be combined with one of the many "software test of function tests including error tests" that is recommended for most elements.

Also, as Anthony stated, it is not necessary and often not possible to insert a fault for every primary diagnostic but there are counter measures and overlap that are used to identify latent faults in case you are striving for ISO26262 considerations. The counter measures and overlaping diagnostics are listed in the test for diagnostic column of table A in the safety manual.

Also, just to be clear, there is a big difference between fault injection and fault insertion according to the IEC61508 standard. For the silicon, it is only possible to do fault insertion since you do not have access to the silicon and cannot physically create a fault. From a system level, this might be possible since you are in control at the system level to create errors in your circuit that might be considered a fault injection. Also worth noting is the terms are usually used interchangeably but this is not correct.