Dear Hercules Team,
My customer has some issue with the VIM_SRAM_PARITY_TEST from our TI Safety Library.
Source File:
sl_selftest.c version 2.3.1
Funkction: Boolean SL_SelfTest_VIM(SL_SelfTestType testType)
Parameter: testType = VIM_SRAM_PARITY_TEST
(Code-line 5282)
/* Check if ESM group1 channel 15 is not flagged */
/*SAFETYMCUSW 134 S MR: 12.2 <APPROVED> Comment_5*/
if (((sl_vimParREG->PARFLG & VIM_PAR_ERR_FLG) == 0U) ||
((sl_esmREG->SR1[0U] & GET_ESM_BIT_NUM(ESM_G1ERR_VIM_PARITY_CORRERR)) == 0U))
{
/* VIM RAM parity error was not flagged to ESM. */
SetCriticalErrorDiag2C(VIM_PARITY_REG, 0U, sl_vimParREG->PARFLG, sl_esmREG->SR1[0U]); <= Added by the customer for diagnostics. Application gets stuck here, until a device reset.
retVal = FALSE;
}
In case of the error, they get stuck at the above mentioned line with the following parameters:
sl_vimParREG->PARFLG: 0x00000000
sl_esmREG->SR1[0U]: 0x00000000
If they comment out this line, the function leaves with retVal = FALSE.
This issue shows up very sporadically (every 1…7 days) in a test system where they run automated test cycles 24/7. The issue seem to show up on different derivatives in use (RM48, RM46, RM42). On RM46 based test systems, it seems to show up more often.
They have also tried to disable interrupts for the time the SL_SelfTest_VIM(VIM_SRAM_PARITY_TEST) function gets executed, without noticeable improvements.
They would like to eliminate the fact, that they make some mistakes when calling this function.
Is there anything specific to take care (timing, dependencies on other tests, interrupts…) when calling this function?
As a possible workaround the customer considers to waive this test (SL_SelfTest_VIM(VIM_SRAM_PARITY_TEST);) and to check the interrupt vector table within the cyclic register test “VIM6 Periodic Software Readback of Static Configuration Registers”. With that approach they would test all interrupt addresses directly.
Would this be an appropriate replacement of the SL_SelfTest_VIM(VIM_SRAM_PARITY_TEST)?
Please let us know, on how to proceed on this issue.
BR,
Matthias
