SL_SelfTest_SRAM Fault Injection callback

Dimitri Di Fulvio

Other Parts Discussed in Thread: TMS570LS3137

Hello,

I'm working with the Safety Diagnostic Library 2.2.0 and I'm using the "TMS570LS3137_NoOS" demo app. I have 2 questions:

1) At line 614 of app_main_NoOS.c the following test is executed:

retVal = SL_SelfTest_Flash(FLASH_ECC_TEST_MODE_2BIT_FAULT_INJECT, TRUE, &failInfoFlash);

From this test (because it's a Fault Injection test) I would expect the generation of an interrupt handled with a callback of the ESM module (in the file esm_application_callback.c) but this doesn't happen.

Same thing goes for this other test that I tried to add to the demo app:
retVal = SL_SelfTest_Flash(FLASH_ADDRESS_ECC_FAULT_INJECT, TRUE, &failInfoFlash);

Is this normal?

2) At line 441 of app_main_NoOS.c the following test is executed:

retVal = SL_SelfTest_SRAM(SRAM_PAR_ADDR_CTRL_SELF_TEST, TRUE, &failInfoTCMRAM);

This test, even if it is a Self-Test, generates an interrupt served by the callback of the ESM module (in the file esm_application_callback.c) but actually it is not handled and considerated unknowncallback. Should I handle the situation in the same way in my project?

Thank you in advance. Regards,

Dimitri

over 9 years ago

0 Bob Crosby over 9 years ago

TI__Guru 72500 points

Dimitri,
Thank you for submitting these questions. I have forwarded them to an expert on the Safety Library.

0 Girish over 9 years ago

TI__Expert 7280 points

Dimitri Di Fulvio said:

Hello,

I'm working with the Safety Diagnostic Library 2.2.0 and I'm using the "TMS570LS3137_NoOS" demo app. I have 2 questions:

1) At line 614 of app_main_NoOS.c the following test is executed:

retVal = SL_SelfTest_Flash(FLASH_ECC_TEST_MODE_2BIT_FAULT_INJECT, TRUE, &failInfoFlash);

From this test (because it's a Fault Injection test) I would expect the generation of an interrupt handled with a callback of the ESM module (in the file esm_application_callback.c) but this doesn't happen.

Same thing goes for this other test that I tried to add to the demo app:
retVal = SL_SelfTest_Flash(FLASH_ADDRESS_ECC_FAULT_INJECT, TRUE, &failInfoFlash);

Is this normal?

Yes, this is normal. To cause the fault, the user application must read from a flash slave address. This is noted in the user's guide.

Note: For FLASH_ECC_TEST_MODE_2BIT_FAULT_INJECT the fault is injected in the subsequent read of the corrupted flash area by the application. The application must take care to restore the flash diagnostic control registers .

Dimitri Di Fulvio said:

2) At line 441 of app_main_NoOS.c the following test is executed:

retVal = SL_SelfTest_SRAM(SRAM_PAR_ADDR_CTRL_SELF_TEST, TRUE, &failInfoTCMRAM);

This test, even if it is a Self-Test, generates an interrupt served by the callback of the ESM module (in the file esm_application_callback.c) but actually it is not handled and considerated unknowncallback. Should I handle the situation in the same way in my project?

Thank you in advance. Regards,

Dimitri

I'll check the behavior and get back to you on this.

- Girish

0 Girish over 9 years ago in reply to Girish

TI__Expert 7280 points

Dimitri Di Fulvio said:

2) At line 441 of app_main_NoOS.c the following test is executed:

retVal = SL_SelfTest_SRAM(SRAM_PAR_ADDR_CTRL_SELF_TEST, TRUE, &failInfoTCMRAM);

This test, even if it is a Self-Test, generates an interrupt served by the callback of the ESM module (in the file esm_application_callback.c) but actually it is not handled and considerated unknowncallback. Should I handle the situation in the same way in my project?

Thank you in advance. Regards,

Dimitri

I verified the reported behavior. This is not expected behavior, and hence a bug in the diagnostics's implementation.

As this is not a fault inject test, the test should not have resulted in an application level callback.

The file esm_application_callback.c is an example file to illustrate handling of the Fault inject tests provided in the SafeTI Hercules diagnostics library. As the SRAM_PAR_ADDR_CTRL_SELF_TEST is not a fault injection, no reference implementation is provided.

To distinguish between the callback occuring due to the SRAM_PAR_ADDR_CTRL_SELF_TEST test against a real Parity error, I recommend that you add handling for this verify that the callback occurred due to the SelfTest API call. You can do this by adding a check of the RAMCTRL register of both the B0TCM and the B1TCM interfaces, as below:

void ESM_ApplicationCallback(uint32 grp_channel, uint32 param1, uint32 param2, uint32 param3)
{
    if((ESM_GRP1_MASK == ((grp_channel&ESM_GRP1_MASK)))&&(ESM_G1ERR_PSCON_COMPARE_ERR == (grp_channel & 0x0000ffff)))
    {
        /*clear nerror and esm flags*/
        sl_esmREG->SR4[0] |= GET_ESM_BIT_NUM(ESM_G1ERR_PSCON_COMPARE_ERR);
        sl_esmREG->SR4[0] |= GET_ESM_BIT_NUM(ESM_G1ERR_PSCON_SELTEST_ERR);
        _SL_HoldNClear_nError();
        pscon_errorforcing_app_callback = TRUE;
    }
    ...
    else if((ESM_GRP2_MASK == ((grp_channel&ESM_GRP2_MASK)))&&(ESM_G2ERR_B0TCM_ADDPAR == (grp_channel & 0x0000ffff)))
    {
        if ((TCRAM_RAMCTRL_ADDRPAR_OVR_MASK & sl_tcram1REG->RAMCTRL) == TCRAM_RAMCTRL_ADDR_PARITY_OVER)
        {
            /* ignore - caused by SRAM_PAR_ADDR_CTRL_SELF_TEST */
        }
        else
        {
            /* real address parity error */
        }
    }
    else if((ESM_GRP2_MASK == ((grp_channel&ESM_GRP2_MASK)))&&(ESM_G2ERR_B1TCM_ADDPAR == (grp_channel & 0x0000ffff)))
    {
       if ((TCRAM_RAMCTRL_ADDRPAR_OVR_MASK & sl_tcram2REG->RAMCTRL) == TCRAM_RAMCTRL_ADDR_PARITY_OVER)
       {
           /* ignore - caused by SRAM_PAR_ADDR_CTRL_SELF_TEST */
       }
       else
       {
           /* real address parity error */
       }
    }
    else
    {
       unknowncallback = TRUE;
    }
}

Arm-based microcontrollers

Arm-based microcontrollers forum

SL_SelfTest_SRAM Fault Injection callback