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: SL_SelfTest_STC(STC1_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig)

Part Number: TMS570LC4357
Other Parts Discussed in Thread: RM48L952

Hi,

the function "SL_SelfTest_STC(STC1_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig)" from the TI Safe Library is not able to reset the CPU. It returns TRUE, which means the parameters are good, but it doesn't reset the CPU, which is necessary to run the CPU Self Check.

The ESM has no errors. 

Would somebody tell me please the reason for this issue?

Thank you very much

  • Hello Rabie,

    There should be a corresponding CPU reset after execution of interval 0. To execute self-check, you must configure the STC so that only interval 0 is executed, can you send the content of the self test config struct so I can check it. This by itself shouldn't prevent the interval execution, but I would like to review it.

    The return value of "TRUE" is really meaningless since it is really just a default return value. In a normal execution of the STC, the return for this function will never be reached since the CPU will reset and then the code should take the path of after a STC run.

    Can you upload startup files and the code where you are initiating the STC self check so I can have a look. Also, which version of the SafeTI diagnostic library are you using so I can be sure to align.
  • Hi Davenport,

    i am using the TI Safety Library 2.3.1

    I attached in this post my startup file.

    Thank you for your help.

    Best Regards.

    4478.TI_Startup.c.txt

  • Hello Rabie,

    My apologies for the delay in getting back to you. I have been looking through your start up code and the SL function and do not see any issues that would result in the STC not kicking off like it should. I am going to forward this to our software lead to see if he has any suggestions about what might be the problem.
  • Hi Rabie,

    You must update your SafeTI Diagnostic Library to version 2.4.0. It is compatible to 2.3.1 and no application software need to change. 

    Reasons:

    1) Ideally SL_Selftest_STC does not return if it started the Test successfully, because once the test starts after CPU Idle "WFI", CPU reset is the only way to recover either by the STC after completing the Test, or external reset.

    2) For you it's returning true because the WFI instruction ( part of _SL_Kickoff_STC_execution  assembly function) was not successfully executed, the main reason could be if any of the interrupts are pending, CPU does not enter IDLE. WFI here works just like any other NOP.

    3) In version 2.4.0 we have fixed this _SL_Kickoff_STC_execution function to be running in a loop until WFI is hit. Please see the snapshot below... 

    I do not know the reason why you are still at version 2.3.1, please go to http://www.ti.com/tool/SAFETI_DIAG_LIB and download latest SafeTI diagnostic library. 

    Hope this helps!! 

  • Hello Prathap,

    We are experiencing the same kind of issue on an RM48L952 chip. In our case, the STC test won't be kicked (1% of the time) when trying multiple reboots inside a climatic chamber.

    We are using the IAR compiler with the Safety Library 2.3.1.

    If the STC test is not kicked because of a pending interrupt, it appears that the code change for 2.4.0 would block forever. Are we missing something?

    Also do you know of a method to safely clear any pending interrupt prior to starting the test?

    Thanks and regards,
    Shazan Lefebvre
  • Hi Shazan,

    • Is STC triggered only during bootup ( Power cycle / System Reset)? If So STC can be triggered before enabling any Interrupts in the system, which will ensure no interrupts are pending. One exception herer id ESN High interrupt which is non maskable. Make sure you clear ESMSR1, ESMSR2 register before starting STC test ( there is an errata DEVICE #56 which can sometime set this bit).
    • If STC test is run periodically with out a reboot of the system that's when we have to be careful because many interrupts channels are enabled and might be triggering. Here service all pending VIM Interrupts ( Check VIM Interrupt Status register) and disable all the VIM channels ( using VIM module register ) before starting the STC test and restore it back along with usual CPU context save and restore. 

    So servicing Pending interrupts and disabling it in VIM ( not just disabling interrupt in CPU using CPSR) is essential when entering STC test.

    Worst case i believe system code can be protected with watchdog, to help come out of such stuck at code?  

    From my experience performing STC at the beginning of Sartup is simpler and doesn't need too much of system stimuli considerations.