S32G Scheck Sram Ecc Test fail

[jiaruo]

Dear Support Team：

We have a problem in use  Scheck SRAM function。

The EB configuration is as follows：

We catch an exception in sCheck_Sram_TestEccCorrError test.

The function returns wrong result at line 365：

Data in watch window：

pParams->u16ErmChanId = 0x129， 

result.memErmFlag = EMCEM_MEM_NO_ERR

Line 375：*pArgs->pu32Signature = 0x5E338001

How can we do to perform the correct scheck_ecc test？

[martinkaspar-r3]

Thank you for your report. An example how to run the STANDBY_SRAM_ECC test is available in SAF demo application provided in the SAF package in folder c:\NXP\S32G_SAF_1.0.1\S32_SAF_Demo. We tried a test in SAF demo and we cannot reproduce the issue there. Also please check all the conditions/limitations as described in sCheck user manual in section “5.7.6.5 SRAM ECC tests The SRAM ECC tests”.

[jiaruo]

Dear Support Team:

Thanks a lot for your apply.

According to my test results, we wanted to know the cause of  ' pErrorContainer->u32Dword[6]  = 0x00040000' error. 

It will be better if you can illustrate the meanings of every byte of pErrorContainer->u32Dword[i]. 

Thanks a lot.

B.R.

Floria

[martinkaspar-r3]

The error container indicates which sCheck test or sub-test has failed. The structure contains array of words, which should be interpreted as a bit field. Each bit in the bit field corresponds to one test of sCheck (and some tests include multiple error bits in this bitfield). The details of this structure are documented in section “3.2.1 sCheck_ErrorContainerType” in sCheck user manual (c:\NXP\S32G_SAF_1.0.1\eclipse\plugins\sCheck_TS_T40D11M10I1R0\doc\S32G_SAF_SCHECK_UM.pdf).

For your case below, i.e.

pErrorContainer->u32Dword[6]  = 0x00040000

0x00040000 is a bit 18 in word 6, so the index is 6*32 + 18 = 210 which corresponds to enum define SCHECK_ERR_STANDBY_SRAM_ECC within enum sCheck_ErrorIndexType. So this only provides information that STANDBY_SRAM_ECC test has failed.

Could you check whether the error is injected properly by checking the ERM instance as in the following screenshot from Lauterbach debugger:

I.e. after executing the sCheck_Sram_ErrRead() function you should see one correctable error detected in ERM_STDBY_SRAM HW module. The function sCheck_Sram_ErrRead() function will setup EIM (Error Injection Module), then it will perform a read from STANDBY SRAM to create the ECC error so after this we should see the error detected in ERM_STDBY_SRAM error reporting module.

[jiaruo]

Thanks a lot for your reply.

We solved the sing bit ECC sCheck right now. But we found some errors on Multi-bit ECC sCheck.

It would generate BUS Error when runned in 'sCheck_Sram_TestEccUncorrError' as attached. 

Could help to check it, please?

Thanks a lot.

[martinkaspar-r3]

Hello,

it seems that the debugger is getting BUSERROR message when it’s trying to read the value of the local variable “result” inside the function “sCheck_CortexM7_ErrRead”. Also the address 0x1 of the argument pParams for the function seems to be incorrect. This indicates that there might have been stack corruption. Is any EIM peripheral enabled (EIM.EIMCR.GEIEIN=1) when you observe the error?

[jiaruo]

Dear Support Team:

We debugged the code and found that the sCheck pErrorContainer as follows:

Could you help to check which errors led to this, please? 

Thanks a lot.