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.

RM44L520: STC self check - positive test is not possible with FAULT_INS = 0 and also timeout issue

Part Number: RM44L520
Other Parts Discussed in Thread: SEGGER, HALCOGEN

Hello,

TRM chapter 8.4.10 description and register content seems conflicting.

Description says that test will always fail:

The STC run will fail for signature miss-compare, provided the signature compare logic is operating correctly.

But description looks to give option to run the check without failure by setting 4th bit (FAULT_INS) to value 0. But based on my experience the STC selfcheck will always fail despite of FAULT_INS bit value, is this behavior expected? SafeTI-library status checker SL_SelfTest_Status_STC()-fucntion returns TRUE and flags ST_FAIL even when FAULT_INS==0 to "st_result", "CPU1Failure" and "CPU2Failure" variables so "TimeoutFailure" is ST_PASS and thus not occured..


Second problem concerns timeout value in STCTPR-register during self check. When running self-check ( STCSCSCR bit SELF_CHECK_KEY == 0xA) the maximum value 0xFFFFFFFF looks to hang-up the CPU somewhere, instead same value works if "STC_RUN" is given as argument to SL_SelfTest_STC()-function. In self check/ phase also value 0x1000 hangs up the CPU and at least values 0x100 and smaller works...

Here is code, where behavior of the start-up test depends on the selected timeout value

        stcSelfTestConfig.stcClockDiv        = 0;             /* STC Clock divider = 1 */
        stcSelfTestConfig.intervalCount     = 1;             /* One interval only */
        stcSelfTestConfig.restartInterval0     = TRUE;         /* Start from interval 0 */
        stcSelfTestConfig.timeoutCounter     = 0x100U; // 0x1000 ---- does not work, hangs cpu ;             /* Timeout counter*/
        _SL_HoldNClear_nError();

        SL_SelfTest_STC( STC_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig );

And here is example of working actual stc test where STC_MAX_TIMEOUT is 0xFFFFFFFF and this works
        stcSelfTestConfig.stcClockDiv        = 0;             /* STC Clock divider = 1 */
        stcSelfTestConfig.intervalCount     = 24;             /* One interval only */
        stcSelfTestConfig.restartInterval0     = TRUE;         /* Start from interval 0 */
        stcSelfTestConfig.timeoutCounter     = STC_MAX_TIMEOUT;             /* Timeout counter*/

        SL_SelfTest_STC( STC_RUN, TRUE, &stcSelfTestConfig );

  • Hello Jarkko,

    I have forwarded your question to our SafeTI Library experts. They should get back with you soon.
  • Hi Jarkko,

    1) I am not sure about your clock settings, but STC clock should be max 90MHz.In your use case I see stcclcockDiv = 0, which mean CPU clock = STC Clock. If you have configured your PLL to be more than 90MHz, the STC might not behave right.

    2) I did a simple test, in which I made SELF_CHECK_KEY = 0xA and FAULT_INS=0, The test completed with No Error Flags set. I tried giving TIMEOUT MAX, it did not Hang.

    Please check the STC clock settings, redo your test and let us know.

  • Hi,

    1) You are right about clock settings, those are not correct acoording to datasheet but fixing them (using stcClockDiv != 0) doesn't help. I used same code as from SafeTI example without further thinking...

    I am running CPU with max speed so HCLK is 180MHz. So using stcSelfTestConfig.stcClockDiv = 1 should be enough

    TRM by the way doesn't mention any restriction but now when got a hint I found following from the datasheet: "The maximum clock rate for the self-test is HCLKmax/2."

    This "fixed" code does not work either where divider is set to 1 to effective divider should be 2

           /* Make sure that the CPU self-test controller can actually detect a fault inside CPU */

        stcSelfTestConfig.stcClockDiv = 1; /* STC Clock divider = xxxx */

        stcSelfTestConfig.intervalCount = 1; /* One interval only */

        stcSelfTestConfig.restartInterval0 = TRUE; /* Start from interval 0 */

        stcSelfTestConfig.timeoutCounter = 0x1000U;    /* Timeout counter*/ /* Timeout 0x100 works but 0x1000 not - hangs cpu */

        vClearAndWait_nError();

          SL_SelfTest_STC( STC_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig );

    And if I change timeout to 0x100 then it again works (and .stcClockDiv is still 1)

    stcSelfTestConfig.timeoutCounter = 0x100U;

    Debugging is also hard if not almost impossible, I am using IAR and segger J-link and haven't figured a way how to really connect to target without reseting it, PC is always pointing to 0x0 what ever I try so the situation is always lost... Have tried from debugger download sheet to only enable "Attack to running target" and then tried both options from "Project->Download and Debug" and also "Project->Debug without downloading"... And also tried every other 'tick the box' combination from debugger download sheet...

    And by the way, "hangs the cpu" was wrong term from me, I have while(1)-loops in every STC expected failure branch so cpu "hangs" because STC test result was not expected...

    I debug it now so that in case STC test start fails or result it not expected I flag situation and jump to afterSTC() function where I then transfer results to no_init_variable which also survives RAM PBIST (I backup data to peripheral RAMs while doing PBIST in CPU RAM) and it survives also c standard variable initializationbefore main (because of  "no_init" keyword). Then in the main I print the result to UART so I can see without debugger that what happened...

    and here are the results when following values are used in self check .stcClockDiv = 1; and .timeoutCounter = 0x1000U;...

    1. Calling SL_SelfTest_STC() == SUCCESS (code does not return)

    2. CPU reset occurs and goes this branch if( (sl_stcREG->STCSCSCR & 0xFU) == STC_STCSCSCR_SELF_CHECK_KEY ) == STC self test was really run

    3. SL_SelfTest_Status_STC() return TRUE == register also indicates that it was really run

    4. Status returned .stResult == ST_FAIL and .TimeOutFailure == ST_FAIL --> NOT OK, timeout should not occur

    I have this kind of code to track (in afterSTC()) what happens during boot-up

    [code]

       if( u32StcStartFailed == 2 )

       {

           initSTFailCount |= 0x80000000;

       }

       if( u32StcStartFailed == 1 )

       {

           initSTFailCount |= 0x40000000;

       }

       if( u32SelfCheckFail == 2 )

       {

           initSTFailCount |= 0x20000000;

       }

       if( u32SelfCheckFail == 1 )

       {

           initSTFailCount |= 0x10000000;

       }

       if( u32SelfCheckFail == 3 )

       {

           initSTFailCount |= 0x08000000;

       }

       if( u32SelfCheckFail == 4 )

       {

           initSTFailCount |= 0x04000000;

       }

       if( failInfostc.stResult != ST_PASS )

       {

           initSTFailCount |= 0x00100000;

       }

       if( failInfostc.CPU1Failure != ST_PASS )

       {

           initSTFailCount |= 0x00200000;

       }

       if( failInfostc.CPU2Failure != ST_PASS )

       {

           initSTFailCount |= 0x00400000;

       }

       if( failInfostc.TimeOutFailure != ST_PASS )

       {

           initSTFailCount |= 0x00800000;

       }
    [/code]

    And result is 0x10900001
    where lsb 1 is error count (every fail in boot sequence increments this variable)

    So we have u32SelfCheckFail == 1 and failInfostc.stResult != ST_PASS and failInfostc.TimeOutFailure != ST_PASS

    And here is the code for that part, which shows that it is the failInfostc.TimeOutFailure != ST_PASS which causes jump to vAfterSTC(), so value 0x1000U as a timeout trigger timeout failure in STC module where value 0x100 or 1 doesn't. This sounds crazy because the bigger the value is the bigger the timeout should be...
    [code]
    void vCpuResetCheckerforSTC( void )
    {
        u32SelfCheckFail = 0;
        // Check if self check run
        if( (sl_stcREG->STCSCSCR & 0xFU) == STC_STCSCSCR_SELF_CHECK_KEY )
        {
            // Check if fault insertion bit was enabled --- test looks to fail also if bit is not enabled
            //SL_SelfTest_Result eExpected = ( (sl_stcREG->STCSCSCR & STC_STCSCSCR_FAULT_INS /*BIT_n( 4U )*/) ? ST_FAIL : ST_PASS );
            SL_SelfTest_Result eExpected = ST_FAIL;
            // clear self-check mode
            sl_stcREG->STCSCSCR = 0x05U;
            // check status of the test
            if( SL_SelfTest_Status_STC( &failInfostc ) )
            {
                u32SelfCheckFail = 1;
                /* clear STC global DONE status flag - STATUS function doesn't do this */
                sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE;

                if( failInfostc.stResult == eExpected )
                {
                    if( failInfostc.TimeOutFailure != ST_FAIL )
                    {
                        // fault insertion: CPU1 & CPU2 should have failed both cpu's and normal should pass both
                        if( (failInfostc.CPU1Failure == eExpected) && (failInfostc.CPU2Failure == eExpected) )
                        {
                            esmREG->SR1[0U] = BIT_n( 27U ); //0x08000000U; // clear ESM group1 channel 27 status flag

                            initSTPassCount++;
                            /* Start CPU Self-Test */
                            vStartSTC( STC_RUN );
                        }
                    }
                }
            }
            else
            {
                u32SelfCheckFail = 2;
            }

            initSTFailCount++;

            afterSTC(); // DEBUG

            while(1){} // TODO: Safe to continue or just kill, if continue must set error
        }
    [/code]

    SafeTI example code has also PLL's and HCLK & GCLK from 160MHz to 220MHz

    #define HCLK_FREQ    160.000F

    #define HCLK_FREQ    180.000F

    #define HCLK_FREQ    220.000F

    And it uses exactly same line in every where

    stcSelfTestConfig.stcClockDiv = 0; /* STC Clock divider = 1 */

    So there is a bug in SafeTI example?

    This check in SL_SelfTest_STC() is also wrong, according to datasheet STCCLK must be always HCLK/2 so value 0 cannot be ever accepted but this checks only upper boundary...

       if(config->stcClockDiv>STC_MAX_CLOCK_DIV){

           SL_Log_Error(FUNC_ID_ST_STC, ERR_TYPE_PARAM, 0U);

           retval = FALSE;

           return(retval);

       }

    Unless this statement in TRM means that in some point HCLK may not follow GCLK or something...

    • Is disabled separately from HCLK using the CDDISx register GCLKOFF bit 0

    2) Great to hear that it works on our desk so it should be possible to do the positive test, but I'll guess that I will not negative results at least as long I have that timeout problem in case 1 so case 1 should be solved first and after that this most probably works also...

  • Just to update

    With this it works so divider more than 2 and timeout is relative small
    stcSelfTestConfig.stcClockDiv = 7; /* STC Clock divider = xxxx */
    stcSelfTestConfig.intervalCount = 1; /* One interval only */
    stcSelfTestConfig.restartInterval0 = TRUE; /* Start from interval 0 */
    stcSelfTestConfig.timeoutCounter = 0x1000U; /* Timeout counter*/ /* Timeout 0x100 works but 0x1000 not - hangs cpu */

    Now my debug trackker shows 14680064dec == 0x00E00000 which means that any of the cludges are not activated and failInfostc shows failure to all other but timeout...

    But if I now increase timeout to 0xFFFFFFFFU it doesn't work any more and behavior is just like before, debug track shows same 277872641dec == 0x10900001 as before...

    So .stcClockDiv indeedly do have some effect in the system but doesn't fix the root cause - I am assuming that self-test forced failure should fail cores not generate timeout and it does core failures if timeout is smalla enough...


    I think that the .TimeOutFailure must be checked in order to be sure that test failure due to cpu1 & cpu2 failure and not due to timeout failure, if thest fails to this timeout failure then it doesn't give any proof that STC is really capable of checkking the cpu's (SafeTI example doesn't check this neither if only checks that upper level shows failure if ((stcREG->STCGSTAT & 0x3U) != 0x3U) )...
  • Just to correct myself once more, and I also found reason for behavior 2

    1)
    I said in previous post this for successful run (with divider 7 and timeout 0x1000:

    "Now my debug trackker shows 14680064dec == 0x00E00000 which means that any of the cludges are not activated and failInfostc shows failure to all other but timeout..."

    There was error, in my sentence above which explain the history behind that "E". In successful run the CPU logic sets STCGSTAT failure bit to 0 but SafeTI-function also checks STCFSTAT-registers and there are every bit always active, so in successfull test (this is now real STC test not selftest) you can only check that "if( failInfostc.stResult == ST_PASS)". And because I always print the latest structure content we will see that 0xE there which indicates that only .stResult was ST_PASS

    I have this kind code to check real STC test results and there are that comment regarding STCFSTAT-content

    [code]
        else if( (sl_stcREG->STCGSTAT & STC_STCGSTAT_TEST_DONE) != 0U )
        {
            if( SL_SelfTest_Status_STC( &failInfostc ) )
            {
                /* clear STC global DONE status flag - STATUS function doesn't do this */
                sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE;

                // Looks to set all failure bits in sl_stcREG->STCFSTAT when success, so check only "stResult"
                if( failInfostc.stResult == ST_PASS )
                {
                    initSTPassCount++;
                    /* Continue start-up sequence after CPU STC completed */
                    afterSTC();
                }
            initSTFailCount++;

            u32SelfCheckFail = 3;
            afterSTC();  // for DEBUG

            while(1){} // TODO: Safe to continue or just kill, if continue must set error
    }
    [/code]


    Do you know why STCFSTAT asserts bits even though STCGSTAT does not show failure?

    2) and that STCFSTAT content while STCGSTAT is ok was by the way also the reason why the positive test failed, as seen in previous posts in self check phase I also check CPUxFailure returned by SafeTI and currently in real STC test I do not check it...

    So now I have added positve self test after negative one and added a couple of more traps (u32SelfCheckFail = 5 and u32SelfCheckFail = 6) and manually do same start up routines for positive test as what SafeTI offers (just do not set that FAULT_INS bit)

    [code]
        if( (sl_stcREG->STCSCSCR & 0xFU) == STC_STCSCSCR_SELF_CHECK_KEY )
        {
            // Check if fault insertion bit was enabled --- test looks to fail also if bit is not enabled
            SL_SelfTest_Result eExpected = ( (sl_stcREG->STCSCSCR & STC_STCSCSCR_FAULT_INS /*BIT_n( 4U )*/) ? ST_FAIL : ST_PASS );
            //SL_SelfTest_Result eExpected = ST_FAIL;
            // clear self-check mode
            sl_stcREG->STCSCSCR = 0x05U;
            // check status of the test
            if( SL_SelfTest_Status_STC( &failInfostc ) )
            {
                u32SelfCheckFail = 1;
                /* clear STC global DONE status flag - STATUS function doesn't do this */
                sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE;

                if( failInfostc.stResult == eExpected )
                {
                    if( eExpected == ST_FAIL )
                    {
                        if( failInfostc.TimeOutFailure != ST_FAIL )
                        {
                            // fault insertion: CPU1 & CPU2 should have failed both cpu's and normal should pass both
                            if( (failInfostc.CPU1Failure == eExpected) && (failInfostc.CPU2Failure == eExpected) )
                            {
                                esmREG->SR1[0U] = BIT_n( 27U ); //0x08000000U; // clear ESM group1 channel 27 status flag

                                stcSelfTestConfig.stcClockDiv        = 1;             /* STC Clock divider = xxxx */
                                stcSelfTestConfig.intervalCount     = 1;             /* One interval only */
                                stcSelfTestConfig.restartInterval0     = TRUE;         /* Start from interval 0 */
                                stcSelfTestConfig.timeoutCounter     = 0x1000U;         /* Timeout counter*/ /* Timeout 0x100 works but 0x1000 not - hangs cpu */

                                register SL_STC_Config* config = &stcSelfTestConfig;

                                #include "sl_reg_system.h"
                                sl_systemREG2->STCCLKDIV = ((uint32)(config->stcClockDiv & (uint32)0x07u) << 24u);

                                uint32 tempVal = 0U;
                                tempVal |= ((uint32)config->intervalCount << STC_STCGCR0_INTCOUNT_START);
                                tempVal |= STC_STCGCR0_RS_CNT;
                                sl_stcREG->STCGCR0 = tempVal;

                                sl_stcREG->STCSCSCR = (uint32)(STC_STCSCSCR_SELF_CHECK_KEY);

                                    /* Setup the timeout value */
                                sl_stcREG->STCTPR = config->timeoutCounter;

                                /* Enable STC run */
                                sl_stcREG->STCGCR1 = STC_STCGCR1_STC_ENA;

                                for (tempVal = 0u; tempVal < 32u; tempVal++) { }

                                /* Kick off the STC execution */
                                _SL_Kickoff_STC_execution();

                                u32SelfCheckFail = 5;
                            }
                        }
                    }
                    else
                    {
                        initSTPassCount++;
                        /* Start CPU Self-Test */
                        vStartSTC( STC_RUN );
                    }
                }
                else
                {
                    if(  eExpected == ST_PASS )
                    {
                        u32SelfCheckFail = 6;
                    }
                }
            }
            else
            {
                u32SelfCheckFail = 2;
            }

            initSTFailCount++;

            afterSTC(); // DEBUG

            while(1){} // TODO: Safe to continue or just kill, if continue must set error
        }
    [/code]

    And the result is same which indicates that no real errors occured during the boot because LSB part of the variable is 0
    14680064 dec == 0x00E00000

    But this test also fails if I now increase divider to 7 (real is 8) while keeping timeout as 0x1000 and my error trap shows 24117249 == 0x0170001 which means that u32SelfCheckFail == 6 which means that  this line failed
    if( failInfostc.stResult == eExpected )
    and eExpected was ST_PASS (so we were doing positive selftest...

    Everyother failure bit is active exept the timeout, how STC clock speed can affect to core testing, shouldn't that generate a timeout error so error  ....

    and I added those new failure traps codes like this
        if( u32SelfCheckFail == 5 )
        {
            initSTFailCount |= 0x02000000;
        }
        if( u32SelfCheckFail == 6 )
        {
            initSTFailCount |= 0x01000000;
        }


    And if I now raise timeout to 0x10000 while keeping divider as 7 (8) the test is passed again and traps shows same 14680064 == 0x00E00000 indicating failures in every other field than .stResult like in every successful case...

    For this case that STCFSTAT gets set even though STCGSTAT does not show failure looks a bug for me, either in the CPU or in the SafeTI... If that bit setting in STCFSTAT is an expected feature then SafeTI should not check them in case of success and instead set structure values to ST_PASS manually...

    TRM doesn't say a much, only that when ENA is set the STCFSTAT should reset to 0 which indicates that  successfull test really raises those failure bit active...

  • Jarkko,

    I forgot to inform one finding which I did few days back. STCFSTAT CPU1 and CPU2 Failure status bit clear feature is swapped. That is, when you write 1 to clear CPU1 FAIL status bit, it clears CPU2 FAIL status bit. Hence SL_SelfTest_Status_STC() which does a clear if there is a CPU1 or CPU2 FAILURE logic has to be revisited / worked around.

    I have raised this issue to Applications Team and Design Team to confirm my finding. There will be an update to Errata sheet if this is confirmed.

    Workaround could be Clearing both CPU1 and CPU2 FAIL status together, or swap the bits to write clear.


    Attaching a simple code( using HALCoGen for RM46x Family) to test this. /cfs-file/__key/communityserver-discussions-components-files/312/3884.sys_5F00_startup.c

  • Hi,

    If that bug is true, then it does not exists (at that specific form) on my device (currently using RM44 series L520PGE)... Because I check in fault-insertion case that SafeTI returns ST_FAILs for both cores and that check is passed and SafeTI clears those bits one by one.


    By the way, why you look to operate with "halcogen"-generated code and in these forums the SafeTI code "is recommended" to use , not HalCoGen stuff, just to easier debug? I have now rather successfully stripped practically all selftest.c related stuff out from the boot and are using SafeTI-functions if they have suport but this was really time consuming practice?


    I think that there is no point to ever clear the STCFSTAT manually if TRM is correct because new test start (STC_ENA) should clear them so why even try to hide that information manually...
    - SafeTI shouldn't do this clearing and that would also fix that possible bug, of course if STC_ENA doesn't work like described then some other manouvers are needed


    My problem is currently mainly the timeout value only
    - why self check fault-insertion test does not work if timeout value is rather large 0x1000 or bigger but works when it is small like 0x100 or smaller - this does not make any sense to me...
    - why self check without fault-insertion fails if timeout is not large enough, does this then actully run 1 cycle, data sheet says that 1 cycle takes 1365 STCCLK which is 0x555 (this would also mean that STC divider shouldn't matter because cycles are as STCCLK). TRM part of STCTPR says that timeout is vbus-cycles and this vbus term is not opened in TRM is it VCLK but then there is VCLK1, VCLK2 and VCLK4, is VBUS just generically HCLK or GCLK / 2 thus cpu speed / 2?

    So if vbus = HLKC/2 and STCCLK divider given as argument (1) meaning 1:2 when VBUS == STCCLK so 0x556 as a timeout should be sufficient - but that isn't positive self check fails (but now to timeout :)) with it, with 0x1000 it works and it works also with 0xAAF which is 0x555*2 plus 5.... So is VBUS actually == HCLK? 0xAA9 works also and 0xA00, those are both less than 0x555 * 2...

    Is TRM part for STCCLKDIV really true? Value 0 == 0 divider, value 1 = 1:1 divider and value 7 = 1:7 divider?
    "26-24 CLKDIV 0 Clock divider/prescaler for CPU clock during logic BIST"
    - In that case both values 0 and 1 would be illegal
    Bute example in TRM 8.5.1. says which would indicate that STCCLKDIV is regular divider register where value 0 means 1:1 divider
    "STCCLKDIV[26:24] = 1"


    I commented out all STCFSTAT acks from SafeTI and that timeoutvalue related issue still shows same, for example positive self check (no FAULT_INS) shows ST_FAILs to every other than timeout if value is 0x556 but passes if value is in 0xAA0 range...


    So with STCCLKDIV:CLKDIV == 1
    - self check negative works if timeout is below 0x100 and fails if over 0x1000 (haven't tested range between those. In case on failure this flags timeout failure not core failures :) (SafeTI STCFSTAT ack disabling doesn't change behavior).
    - self check positive works if timeout 0xAA0 but does not work is 0x556 (haven't tested range between). In case of failure flags core failure not timeout :) (SafeTI STCFSTAT ack disabling doesn't change behavior)
    - actual STC works/passes if timeout 0xFFFFFFFF (havent tested other values)

    So timeout works strangely if "improper" value (value should be ok, for example FAULT_INS shouldn't care whether the value is 0x100 or 0x1000, SafeTI example uses "for some reason" value 1 not 0xFFFFFFFF which is given by default to actual STC test) is given the received feedback from STCFSTAT is weird...


    If you bug is correct, it must concern only some devices, but I am pretty sure that in my device there is something else wrong in the CPU...
  • Hi Jarkko,

    - The bug I mentioned is not applicable to RM44 and TMS570LS07x / 09x Family of Devices.

    - To comment on your STCFSTAT Clear, From TI's perspective we cannot predict how customer would like to clear, understand that  STC_ENA can be used, but incase of actual failure, there may way customer would like to handle. So it's up to the user.

    Coming to Problems you are facing.  Below Test I performed using STC Self Test on RM44 device.

    TIMEOUT  (Test Cycles) FAULT_INS SELF_CHECK_KEY GSTATUS FSTATUS Interval Test Status Comments
    MAX 1 0xA 3 3 1 Test Successful
    0x1000 1 0xA 3 3 1 Test Successful
    Max 0 0xA 1 0 1 Test Successful
    1400 0 0xA 1 0 1 Test Successful As per the CPU Self Test Coverage Table in data sheet, for Interval 1, 62.13% coverage, take around 1365 Cycles, Hence I configured value 1400 for TImeout.
    1300 0 0xA 3 4 1 Test Successful Timeout Error Generated


    What i infer is SELF TEST(0xA) with out FAULT_INS is equal to STC RUN ( 0x5), so it runs for 1 interval as per Table mentioned in the Datasheet.

  • Hi,

    Many thanks for testing...

    I think that I figured now out what was the main problem...

    It was that in SafeTI that the .stResult polarity is different than others. for stResult ST_PASS == no error in self test and for other ST_PASS == error in that bit. I read the source code multiple times but could spot that when implementing the reason checks, maybe because ST_PASS name (pass) was so strong indication that it will "of course" mean ok not the fail...

    Also self test with fault insertion enabled looks to perform regular selftest so if you put like in SafeTI example the timeout to 1 it does not actually test cores -> test fails to timeout and example code does not check the error reason as I did...

    So after I fixed the checking polarity for others than .stResults this looks to operate without errors.


    So here is the corrected function which test that failure is found from cpu cores (requires proper timeout so that does not fail to timeout) and same check also check that failure are not found if FAULT_INS == 0...

    if( (sl_stcREG->STCSCSCR & 0xFU) == STC_STCSCSCR_SELF_CHECK_KEY )
    {
    // Check if fault insertion bit was enabled
    SL_SelfTest_Result eExpected = ( (sl_stcREG->STCSCSCR & STC_STCSCSCR_FAULT_INS /*BIT_n( 4U )*/) ? ST_FAIL : ST_PASS );

    // clear self-check mode
    sl_stcREG->STCSCSCR = 0x05U;
    // check status of the test
    if( SL_SelfTest_Status_STC( &failInfostc ) )
    {
    if( eExpected == ST_FAIL )
    {
    failInfostc_selftest_fault = failInfostc;
    }
    /* clear STC global DONE status flag - STATUS function doesn't do this */
    sl_stcREG->STCGSTAT = STC_STCGSTAT_TEST_DONE;

    if( failInfostc.stResult == eExpected )
    {
    if( failInfostc.TimeOutFailure == ST_FAIL ) // no timeout
    {
    // fault insertion: CPU1 & CPU2 should have failed both cpu's and normal should pass both
    if( (failInfostc.CPU1Failure != eExpected) && (failInfostc.CPU2Failure != eExpected) ) // ST_PASS == test failed
    {
    // STC self test ok...



    I asked also about that VBUS, does this now mean that divider 0 (1:1) is ok to use, at least it looks to work and example uses that also, or does it only work by luck and SafeTI interface should check that given .stcClockDiv != 0?
  • Hi,

    I actually just realized that I filed a Documentation Enhancement Request for this back in November: SDOCM00122802

    Detailed Description:
    "The meaning of the three detailed fault fields in this struct is counterintuitive to me, please improve the documentation to make this more clear.
    Here is a short description of the meaning for all four fields:
    In an STC pass case (stResult==ST_PASS), CPU1Failure, CPU2Failure, TimeOutFailure should all be ST_FAIL.
    In an STC failure case (stResult==ST_FAIL), one or more of CPU1Failure, CPU2Failure, TimeOutFailure would indicate ST_PASS to indicate that as the reason of failure."

    So it should be taken care of this in the next release.

    Best Regards,
    Christian
  • Hello again,

    We switcher to RM48 CPU and my STC stopped working, immediately remembered this and put comment on SafeTI CPU1 error reason line

    #if defined(_TMS570LS31x_) || defined(_TMS570LS12x_) || defined(_RM48x_) || defined(_RM46x_) || defined(_RM42x_) || defined(_TMS570LS04x_)
    /*SAFETYMCUSW 134 S MR: 12.2 <APPROVED> Comment_5*/
    if (STC_STCFSTAT_CPU1_FAIL == (STC_STCFSTAT_CPU1_FAIL & sl_stcREG->STCFSTAT)) {
    //sl_stcREG->STCFSTAT = STC_STCFSTAT_CPU1_FAIL;
    failInfostc->CPU1Failure = ST_PASS;
    }
    #endif

    After that STC started to work (negative, positive & actual self test with all struct fields returned by HalCoGen checked in my application).

    Can you verify that your bug concers also RM48 not only RM46? Errata for RM48 does not mention it
    www.ti.com/.../spnz223b.pdf
  • Hi Jarkko,

    On the STC CPU FAIL status, I tried on older versions of RM48, RM46, RM42 and RM41 all show same behavior. ( Older version of TMS570LS31x, 21x, 1x, 04x, 03x, 02x also should have this issue) .

    RM44 does not have this issue, it's the latest device released in Hercules family. ( TMS570LS09x, 07x should not have this issue). 

    The behavior should be same for 


    I have raised this concern to the Application Team who are responsible for updating the Errata Sheet after confirmation from their side.

    The STC Hardware IP versions are same for the latest version of above devices, hence I expect this issue should not be present in latest version of the devices.