• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 302 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: Online SRAM selfstest

Charles Obry
Prodigy 115 points
Part Number: TMS570LC4357

In the context of a ISO-26262 ASIL-C system and using the THMS570LC4357 DSP,

 

Based on the SafeTI manual and the FMEDA, it is clear what are the offline tests for the SRAM.

But for the Online test I need some clarifications.

 

 

At the DSP startup, we can enable the ECC and run the PBIST to selftest the RAM.

 

At run-time: The RAM ECC module with SECDEC would ensure a Detected Dual fault point.

Also perform readback of configurations registers.

 

Are these methods sufficient for an ASIL C ?

 

 

Or we need to test the RAM dynamically to increase the coverage (PBIST and CRC) ?

 

But in order to perform live tests, we would need to backup the RAM, do the test and finally restore RAM.

It would help if we only process small portions of the RAM at a time, but it still needs a lot of processing and can be fairly complicated to take into consideration all RAM allocations and their MPU settings, etc.

 

 

Thus, these online tests can performed at shutdown of the system, before power off.

Is running the RAM PBIST only at startup is enough or it needs to be run at power-off before shutdown ?

One reason I could see to run the PBIST tests at shutdown is to check if temperature could have an effect on SRAM.

(In most cases, temperature would be higher at shutdown than startup).

 

What are the methods that you recommend ?

Best Regards,

Charles

  • 0
    TI__Mastermind 49120 points

    Hi Charles,

    See my comments below, in blue and marked by >>:

    At the DSP startup, we can enable the ECC and run the PBIST to selftest the RAM.

    At run-time: The RAM ECC module with SECDED would ensure a Detected Dual fault point.

    Also perform readback of configurations registers.

    Are these methods sufficient for an ASIL C ?

    Or we need to test the RAM dynamically to increase the coverage (PBIST and CRC) ?

    >> A fault in an SRAM location that is not accessed by the CPU is considered to be a latent fault, which in the presence of another fault (e.g. in CPU's ECC mechanism) could result in the violation of the system's safety goal. Latent faults are detected by the PBIST mechanism. How often you need to execute the PBIST on the SRAM depends on your application's fault tolerant time interval (FTTI) and the multiple point fault detection interval.

    >> In ISO 26262-1, the Fault Tolerant Time Interval (FTTI) is defined as the time-span in which a fault, or faults, can be presented in a system before a hazardous event occurs.
    >> Moreover, according to ISO 26262-1, the Multiple-Point Fault Detection Interval (MPFDI) is the time span to detect multiple-point fault before it can contribute to a multiple-point failure.

    But in order to perform live tests, we would need to backup the RAM, do the test and finally restore RAM.

    It would help if we only process small portions of the RAM at a time, but it still needs a lot of processing and can be fairly complicated to take into consideration all RAM allocations and their MPU settings, etc.

    >> PBIST is a destructive test, which is why it makes most sense to execute it on start-up and/or shut-down of the system. As you stated, it is also possible to execute PBIST during execution of the application. This is more involved but certainly feasible. It does require not using any global variables and careful management of stacks and MPU configuration for the CPU scratch pad memory.

    Thus, these online tests can performed at shutdown of the system, before power off.

    Is running the RAM PBIST only at startup is enough or it needs to be run at power-off before shutdown ?

    One reason I could see to run the PBIST tests at shutdown is to check if temperature could have an effect on SRAM.

    (In most cases, temperature would be higher at shutdown than startup).

    >> You can execute the PBIST routines before shut-down to evaluate if higher temperature has an effect on the SRAM. Depending on the time it takes for the PBIST to execute, you could also run it on start-up to make sure that the SRAM does not have any latent faults before executing your safety-critical application. 

    What are the methods that you recommend ?

    >> All safety mechanisms and diagnostic features are described in the safety manual and their effectiveness is quantified in the FMEDA spreadsheet. We cannot make any specific recommendations beyond this as it is very much dependent on the end equipment and the safety integrity level being targeted.

    Regards,

    Sunil