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: SRAM test cleanup

Part Number: RM46L430

Is the concern and need to back up and restore SRAM before SL_SRAM_TEST as described in this post:

https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/601225/2215521

still applicable for STL version 2.40?

Was the method suggested by Mark below deemed necessary and complete or in version 2.40 the context backup and restore happens automatically in the library?

From Mark:

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.

  • Hello Guy,

    Sorry for the delay in responding to your query.

    The Userguide for v2.4.0 was updated which mentions that the user would need to provide a special esm_handler routine without any stack or other RAM access to avoid unexpected error reporting while calling the SL_SelfTest_SRAM.

    I'm looking into this and will get back to you shortly with more details.

    Thanks and Regards,
    Akshay
  • Thanks Akshay. I'm waiting for the details. I've seen the "special esm_handler routine without any stack" comment in the SL as well but it says the default implementation uses stack. An example of how to accomplish this without stack or access to RAM will be greatly appreciated
  • Hello Guy,

    Guy Tadi said:

    Is the concern and need to back up and restore SRAM before SL_SRAM_TEST as described in this post:

    https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/601225/2215521

    still applicable for STL version 2.40?

    I checked with the previous version and found there were no changes made here. So yes, this is still applicable in Safety Diagnostic Library v2.4.0.

    Currently we do not have an example on how to accomplish this without stack or access to RAM. 

    Thanks and Regards,

    Akshay

  • Akshay Manikantan said:

    ..., this is still applicable in Safety Diagnostic Library v2.4.0.

    Currently we do not have an example on how to accomplish this without stack or access to RAM.

    Can someone skilled with this processor and tests please provide code snippets or description of how one would go about accomplishing this without stack or access to RAM? As you can imagine, the library function isn't of much use if it uses stack and RAM as stated. I can't afford to go on a blind date so any technical guideline/input from TI beyond the requirement statement will be very helpful. Thanks.

  • Guy Tadi said:

    Akshay Manikantan

    ..., this is still applicable in Safety Diagnostic Library v2.4.0.

    Currently we do not have an example on how to accomplish this without stack or access to RAM.

    Can someone skilled with this processor and tests please provide code snippets or description of how one would go about accomplishing this without stack or access to RAM? As you can imagine, the library function isn't of much use if it uses stack and RAM as stated. I can't afford to go on a blind date so any technical guideline/input from TI beyond the requirement statement will be very helpful. Thanks.

    Hi,

    From the thread which you have linked in your question, it isn't clear which SRAM diagnostic test is in question  - though it mentions SRAM address parity test, it hints that this is a problem with all SRAM diagnostics.

    The demo application provided inside the Hercules Safety diagnostic library package runs all SRAM diagnostics sucessfully. The thread appeared to focus on SRAM address parity test, and we have verified that that the behaviour of the SDL implementation is correct inside the demo application.

    Please let us know if you have any specific questions.

    thanks,

    Girish