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.

RM46L430: SafeTI Diagnostics Library test SL_SelfTest_SRAM does not cleanup after itself

Part Number: RM46L430

Hello,

The SL_SelfTest_SRAM tests do not leave the controller in the same state as before the tests are run.

The some odd & even RAM error status bits are left set.

The odd & even ECC memory writes are left on.

The odd & even ECC threasholds are changed.

The odd & even test modes are left on.

There is nothing in the SafeTIDiagnosticLibrary-User'sGuide-v2.3.1 that explains that there are post-test steps required.

Am I missing an errata?

Regards,

Mark.

  • Hello Mark,

    As is evident from your experiences, it is expected that the application would save the context before and after the execution of the test to maintain application continuity. I understand you comments about the lack of detail in the documentation to document this assumption and this will be fed back to our software team as an improvement item.
  • Are you talking about SRAM_LIVELOCK_DIAGNOSTICS-test?

    What it tests (which unique identifier this is)? Why it doesn't check nor set any results into SL_SelfTest_Result* sram_stResult? That does not look to be fault_injection test based on the name of test so according to manual it shall set that result since only fault inject ones doesn't do it....

    This test also makes some backups (RAMTHRESHOLD's) (those are actually taken twice, once before "switch-statement" and inside case. SRAM_ECC_ERROR_PROFILING profiling makes same but it restores the settings after the test. This is again also a "great example" of the "code quality", you store settings twice in a row and never use the first stored results and in this LIVELOCK case you never use any of the stored data...

    This SRAM_LIVELOCK_DIAGNOSTICS-test look not completed to me (like raw potato) is that actually real test which should be used? If yes, which unique identifier this is?

    Also why you set auto variable in the end of the function (and in many other functions) to _sl_fault_injection=FALSE; this is useless and just wastes CPU cycles... You also never use that variable in that SRAM function (other function uses it), only set it twice... Again "great example" of "code quality"...

  • Hello Mark,

    After re-visiting this thread, I am gong to open a ticket regarding your observations. Can you provide more details on which specific test modes you were exercising? i.e., fault injection vs self tests, single bit vs. double bit errors, etc. The more details I have the better I can document for our SW team to reproduce.

  • Hello Jarkko,

    can you open a separate post with these specific issues noted for the SRAM livelock test? This will help us keep better track of the sources of any related bug tickets we need to open.
  • Hi Chuck,

    This is what I had to do to get all of the the ‘SL_SelfTest_SRAM’ tests run through and report a pass.

    Insert a wrapper exception handler around the IRQ / FIQ and intercept the ESM high and low priority interrupt handlers, and in the wrapper:

                if test == SRAM_PAR_ADDR_CTRL_SELF_TEST then

                            ESM SR2 = 0x00000400

                            VIM IRQ INTREQ0 = 0x00000001

    Before each call to ‘SL_SelfTest_SRAM’:

                Save TCRAM Even & Odd RAMCTRL

                Save TCRAM Even & Odd RAMTHRESH

    After each call to ‘SL_SelfTest_SRAM’:

                Restore TCRAM Even & Odd RAMCTRL

                Restore TCRAM Even & Odd RAMTHRESH

                Read to unlock TCRAM Even & Odd RAMPERADDR, RAMSERRADDR, RAMUERRADDR

                Clear ESM SR3 0x00000028

                Clear and ERROR pin and reset the key to normal

    Not all steps are required for each test, but that are all required to get all tests to report a pass.

    Regards,

    Mark.

  • Thanks for the additional information Mark! I will forward this to our SW lead and check if this is as expected. if not, we will open a ticket so that we can make improvements to the library. Appreciate your feedback on this. It is very helpful.