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.

RM48L540: VIM_SRAM_PARITY_TEST gets stuck; TI Safety Library

Part Number: RM48L540

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.



  • Hello Matthias,

    1. After reset, the VIM RAM (interrupt vector table) and the parity bits is not initialized, please initialize the VIM RAM before using it.
    2. If you do PBIST to VIM RAM, please do VIM RAM memory initialization after PBIST.
    3. When you get error (breakpoint at SetCriticalErrorDiag2C()), please manually check the value at 0xFFF82408 and 0xFFF82000. The correct value at 0xFFF82408 should be 0x1, and value at 0xFFF82000 should be 0x0.
    4. Did you try the latest version of the library, V2.40?