TMS570LS1224: SafeTI Diag Lib - SRAM_ECC_ERROR_PROFILING

Michal Timm

Part Number: TMS570LS1224

Dear Sirs,

I am working on update of my SafeTI implementation.
I would like to add some periodic tests of SRAM to my current implementation. Example below:

    /* Run SRAM_ECC_ERROR_PROFILING test on TCMRAM */
    retVal = SL_SelfTest_SRAM(SRAM_ECC_ERROR_PROFILING, TRUE, &failInfoTCMRAM);

Unfortunately, it seems it could not work. In SL_SelfTest_SRAM() [sl_self_test.c] there is the switch case structure (line 185). Case 'SRAM_ECC_ERROR_PROFILING' starts at line 375.

    case SRAM_ECC_ERROR_FORCING_1BIT:
#if defined(_TMS570LS31x_) || defined(_TMS570LS12x_) || defined(_TMS570LS07x_) || defined(_TMS570LS09x_) || defined(_RM48x_) || defined(_RM46x_) || defined(_RM44x_) || defined(_RM42x_) || defined(_TMS570LS04x_)
    case SRAM_ECC_1BIT_FAULT_INJECTION:
    case SRAM_ECC_ERROR_PROFILING:
    case SRAM_ECC_ERROR_PROFILING_FAULT_INJECT:
#endif
#if defined(_TMS570LC43x_) || defined(_RM57Lx_)
        /* Clear any previous diagnostic errors status bits [22,21,20,19,12,11,10, 4] - required before trigger */
        sl_l2ramwREG->RAMERRSTATUS = L2RAM_RAMERRSTATUS_CLRALL;
#endif

        if(SRAM_ECC_ERROR_FORCING_1BIT == testType)
        {
            (void)SL_FLAG_SET(SRAM_ECC_ERROR_FORCING_1BIT);
        }

As you can see there are 4 cases with one implementation but only for one of them macro SL_FLAG_SET() is being used. Actually information that the specific test is being performed was saved.This flag can be used e.g. for handling exceptions in _exc_data_abort().

Currently, when I call SL_SelfTest_SRAM(SRAM_ECC_ERROR_PROFILING, TRUE, &failInfoTCMRAM) my program goes into _exc_data_abort() and I cannot handle this situation because the proper flag was not set inside SL_SelfTest_SRAM(). How can I handle this test properly?

Thank you.

over 3 years ago

0 QJ Wang over 3 years ago

TI__Guru**** 198766 points

Hi Michal,

SRAM_ECC_Error_Profiling test is to check if 1-bit ECC error is generated and if the RAMOCCUR gets incremented. It should not generate data abort.

0 Michal Timm over 3 years ago in reply to QJ Wang

Intellectual 810 points

QJ Wang said:
Michal

Hi QJ Wang,

1. I call the same function during boot time (inside _c_int00()) and it not generate data abort.
In the line 413 (sl_selftest.c) there is the assignment:

eccB1 = eccB1 + (0x00400000u/sizeof(uint64));

In consequence essB1 points to location outside RAM:

In the line 451 there is XOR operation on data that essB1 pointed to:

*eccB1 ^= TCRAM_SYN_1BIT_DATA_ECC;

The test is passed.

When I call this function in my program it generates data abort at line 451 (sl_selftest.c)

As u can see above this eccB1 points to location outside RAM. In my software I use FreeRTOS and MPU. So I suppose the reason to the abort is that the location of that pointer is outside ecpected RAM location. Could you confirm? One more question is, should this kind of RAM test be performed in other way or should not be performed when MPU is used?

0 QJ Wang over 3 years ago in reply to Michal Timm

TI__Guru**** 198766 points

Michal Timm said:
So I suppose the reason to the abort is that the location of that pointer is outside ecpected RAM location. Could you confirm?

This (staring from 0x08400000) is the RAM ECC memory, not the RAM data memory. This memory location (from 0x08400000) is in valid memory range.

It can be performed when MPU is enabled, and selftest should be performed in privileged mode instead of user mode.

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LS1224: SafeTI Diag Lib - SRAM_ECC_ERROR_PROFILING