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.

RM46L852: Occurance Register in SRAM Wrapper doesn't count up on ecc-fault correction

Part Number: RM46L852

Hello!

I'm trying to get the SRAM Correctable ECC Profiling ( Safety Manual RM46x 7.94 ) running. I use the TI Safety Library.

By using > SL_SelfTest_SRAM(SRAM_ECC_1BIT_FAULT_INJECTION,TRUE,&sram_stResult); < I already can inject a fault, to trigger a ESM_Callback reaction. Now when i use SRAM_ECC_ERROR_FORCING_1BIT as testType i dont get a reaction at all. What is the difference between those two testTypes?

Also the Occurence Register in the RamWrapper doesn't count at all, so the threshold can't be reached to generate an interrupt.

I used the functions _sl_pmuInit_(); and _SL_Init_EnableEventExport(); to initate the PMU. 

Can you tell me, how to configure that feature correctly?

regards

Mathias

  • Hello Mathias,

    I am looking into your question and will get back with you as soon as I have more information to share. My apologies for the delay.
  • Hello,

    Have you already found some answers/information?

    regards

    Mathias
  • Hello Mathias,

    Unfortunately, our expert has been out of the office recently. I will touch base with them again to see if we can find a solution for you soon.
  • Hello Mathias,

    Again, sorry for the delay in getting back with you.

    The difference between the two test types is that for the SRAM_ECC_1BIT_FAULT_INJECTION option, the ESM error is cleared within the safety library function. i.e., inject the fault, test that the fault is detected/caught/corrected, then clear any ESM errors associated with the injectino of the fault. The SRAM_ECC_ERROR_FORCING_1BIT test type, does not clear the ESM error which allows for the execution/test of your ESM error handler as well as verification that the fault is detected.

    In regard to the ECC threshold register, it seems that the code is restoring a backup value to the ECC threshold register prior to exit/return. This is, most likely, the reason you are not seeing the counter increment and interrupt occur.
  • Hello Chuck,

    Thank you! In the meantime i could figure out something similar/additional.

    For SRAM_ECC_1BIT_FAULT_INJECTION option the ESM interrupt for B0TCM and B1TCM is not disabled for the test (sl_selftest.c line 381). It is only disabled for SRAM_ECC_ERROR_FORCING_1BIT and SRAM_ECC_ERROR_PROFILING type. That is why i would only see the esmGroup1Handler for ESM_G1ERR_B0TCM_CORRERR- and ESM_G1ERR_B1TCM_CORRERR-cases jump in for the fault injection option.

    As i can see in the library (sl_selftest.c line 504) i should be exactly the opposite of what you said. In the SRAM_ECC_1BIT_FAULT_INJECTION option the ESM error won't clear in the Library, in SRAM_ECC_ERROR_FORCING_1BIT option it will. At least it says so, because i still have to clear ESM Status and sl_tcram1(2)REG->RAMERRSTATUS in the ESM Callback for all options. But that is no problem for me now, maybe just interesting to know why the function works like that in my case.

    For the threshold register i agree with you. The threshold register is saving the actual value as backup, uses another for the test ( value 1 for all non-profiling types) restores the old one at the end. That is why the interrupt would still work when i used the fault injection mode even though i set the threshold to ten or anything above one.
    In sl_selftest.c line 417 to 421 RAMOCCUR is set to zero for the test. Because the previous value doesn't get stored and recovered, the counter for correctable ECC Errors will be zero after each test. That is why i don't see the counter increment.

    By commenting out those lines which would disable the interrupt or would set occurances to zero and threshold to another value i fixed the problem and ecc profiling is working fine now.
    Ofcourse this is not how the functions are supposed to work but i wanted to test the function and make the reactions on errors visible, to understand how the feature works.

    thanks and regards

    Mathias Seesko
  • Hello Mathias,

    very good assessment of the function and thank you for having the persistence to follow through with it. I know the code can be very difficult to follow given all of the commented safety designators , signoffs, and code validation instrumentation that is included in the file. I may very easily have reversed the use of the two defines. If so, my apologies for that. I am glad that you were able to get what you needed in the end and that everything is working to your satisfaction and understanding at the moment.