• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 325 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.

TMS570LS0432: About the safety of CPU hardware

whong zhao
Genius 4190 points

Part Number: TMS570LS0432

Dear 

Team

I am sorry .I have some problems, thank you .

1.

If the startup self-check is pass, sys_startup.c 

Can I explain that the hardware of the CPU is okay, and I can use ECC and hardware CRC

2.

when the cpu is running，how does the self hardware check work ，is it working? Does it need software trigger? Is it automatic inspection?

3.

when the cpu is running，if the hardware error ，What will happen

  • 0
    TI__Guru**** 200946 points

    1. Please refer to the appendix A of safety manual. The CPU section lists all possible diagnostic tests and the test for diagnostic. SRAM and flash sections include the diagnostic test for flash/sram ECC.

       For example, If the following tests pass, the CPU can be trusted for code execution: CPU selftest, STC self-check, CCM self-check

       STC self-check: Make sure that the CPU self-test controller can actually detect a fault inside CPU

       CCM self-check: Make sure that CCM-R4F is working as expected.

    2. Do you mean CPU selftest? 

  • 0 in reply to QJ Wang
    Genius 4190 points

    Hello

    I want to know whether the CPU has a mechanism that uses hardware to check all the time, without software triggering. Hardware checks can always run during all time. For example, the API functions in the CPU selftest and STC self-check in security libraries,which need to be called periodicity by software.

  • 0 in reply to whong zhao
    TI__Guru**** 200946 points

    Please check with your assessor if the periodic STC selftest and PBIST are required. In most use cases, a one time execution at boot time is good enough. After that, the CPU lockstep and ECC logic for SRAM will perform the continuous diagnostic. 

    In the case of lockstep cores, the second core is constantly executing the same instructions/code as the primary core and the outputs of each core are continuously compared through the core compare module (CCM-R4F). The lockstep diagnostic is continually operating from power-on reset. If there is a malfunction in one of the two cores, this will be caught by the diagnostic (compare). In addition, the code execution is delayed by 2.5cycles to provide a temporal diversity and the cores are flipped and rotated from each other to provide a physical diversity, and each core has a dedicated power ring to provide a power diversity. This concept is very well thought out, has been reviewed by many certification entities, and has been widely accepted. 

    During the first cycles of CPU operation after reset, it is necessary to execute a short initialization code that sets all CPU registers to a known state. (    _coreInitRegisters_())

    In regard to PBIST, a one time execution at startup proves integrity over the entirety of RAM. During application run time, SECDED takes over as the active diagnostic and prevents/notifies of any issues with RAM. Note that PBIST is not designed to be ran periodically in that it is a destructive test. ECC for SRAM needs to be enabled in sys_startup.c (_coreEnableRamEcc_()).

  • 0 in reply to QJ Wang
    Genius 4190 points

    Thank you 

     If there is a malfunction in one of the two cores, this will be caught by the diagnostic (compare).

    If there is a fault, what kind of response is there, is it through the ERROR pin?
    If I did not use TPS65381, then this diagnosis is not true.

  • +1 in reply to whong zhao
    TI__Guru**** 200946 points

    Hello Whong,

    The basis of TMS570 chip architecture and fault reporting is to assert the nERROR pin so the external system can be notified and appropriate action can be taken. In many cases, we assume that a reset will be taken to correct any transient faults that might cause the failures so the assertion of nERROR is intended to signal externally for this (thus the HFT = 0).