Safety diagnostic library error on SL_SelfTest_SRAM

Hi Davide,

Are you calling SL_Init_Memory(RAMTYPE_RAM) and SL_Init_ECCTCMRAM(threshold,TRUE) in your project's "sys_startup.c" ?

Moreover, currently when you hit  _excpt_vec_abort_data and enter the  _excpt_vec_abort_data() function in "exception_handlers.c", after which line does the program jump to _excpt_vec_udef_instr ?

Thanks,

Vivs 

I'm using 'sys_startup.c' of the demo application version 2.2.0, as attached below. The excpt_vec_abort_data happens when I run the function
SL_SelfTest_SRAM(SRAM_ECC_ERROR_FORCING_2BIT, TRUE, &failInfoTCMRAM) at line 403.

retVal = SL_SelfTest_SRAM(SRAM_ECC_ERROR_FORCING_2BIT, TRUE, &failInfoTCMRAM); /* line 403 */

the exception data abort is handled in the 'exeception_handlers.c' file, correctly.
But the problem is that the exception is triggered in a line of C code different from that of the demo application. It is triggered when it run the return of 'SL_FLAG_SET'
function al line 234 of the function SL_SelfTest_SRAM in the 'sl_selftest.c' file, as attached below.
This does not happen in the demo application. I don't undestand why.

4774.sys_startup.c

7853.sl_selftest.c

2112.exception_handlers.c

Thank you & Best Regards

Davide

Davide,

In SRAM_ECC_ERROR_FORCING_2BIT, the expected behavoir is a data abort caused by reading sramEccTestBuff[2] buffer. Then this abort is handled by _excpt_vec_abort_data() and the program control returns to SL_Selftest_SRAM(). The code snippet from "sl_selftest.c" provided below depicts this:

------------------------------------------------------------------------------------------------
*eccB1 ^= TCRAM_SYN_2BIT_DATA_ECC; /*line 206 - manipulating ECC bits for sramEccTestBuff[2] injecting 2-bit fault*/
_SL_Barrier_Data_Access(); /*line 207*/
*eccB2 ^= TCRAM_SYN_2BIT_DATA_ECC; /*line 209 - same operation as in line 206 but for sramEccTestBuff[3]*/
_SL_Barrier_Data_Access(); /*line 210*/

ramRead = sl_tcram1REG->RAMCTRL; /*line 224*/

if(SRAM_ECC_2BIT_FAULT_INJECT == testType) /*line 227*/
{
 SL_FLAG_SET(SRAM_ECC_2BIT_FAULT_INJECT); /*line 229*/
}
else
{
 SL_FLAG_SET(SRAM_ECC_ERROR_FORCING_2BIT); /*line 234*/
}

_SL_Barrier_Data_Access(); /*line 241*/
ramread64 = sramEccTestBuff[2]; /*line 246 - This read should cause the data abort*/
_SL_Barrier_Data_Access(); /*line 247*/
------------------------------------------------------------------------------------------------

I used the 3 files provided by you in the previous message and saw the data abort being caused by line 246 (and not line 234), which is the expected behavior. If you are seeing the data abort at line 234, my guess is that a premature read of sramEccTestBuff[2] is happening (by the memory browser?). Moreover as you are seeing the abort being handled correctly in _excpt_vec_abort_data(), this implies that the abort was indeed caused by a read of sramEccTestBuff[2] (and not due to some bug in SL_FLAG_SET routine).

Thanks,
Vivs

Vivs,

first of all thanks for your time. Below I'm attacing my project to test the safety diagnostic library. Run only the module 'sys_startup.c'  until the line 718, (the other part of the program are not relevant for this issue, I think ...  )

you can find the following function:

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

run the program in debug mode, step into the function SL_SelfTestSRAM, put one break point to 234 line, you will reach the function:

SL_FLAG_SET(SRAM_ECC_ERROR_FORCING_2BIT);

step into to that function, when execute the assembler C code 'return sl_priv_flag_set[flag_id]', in particular the assembler line:

0003f988: E7D0000C ldrb r0, [r0, r12]

the program raise an exception.

I attached the zip file of my project.

2055.SV107_FW_Test_V21_SL.zip

Thank you & Best Regards

Davide

Vivs,

our problem is solved and we are very happy about it. Since we are using the safety diagnostic library on a SIL2 project, can we assume that this library is well tested and so reilable ?

Of course, one bug can happen but we would like to know if we should expect more.

Thak you for your precious help

Best Regards

Davide

Davide,

Yes, the safety diagnostic library has undergone thorough static and dynamic testing and you can remain assured about its reliability. The forementioned bug never came up in the test analysis since we are nowhere using the return value of the flag. There's no reason to expect more.

Thanks,

Vivs