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.

Why the SL_SelfTest_SRAM(SRAM_RADECODE_DIAGNOSTICS, TRUE, &failInfoTCMRAM) can trigger interrupt?

Other Parts Discussed in Thread: RM48L950, RM48L530, HALCOGEN

Hello:

I am debugging the safety library. As the title, when I debug the startup.c, I find the SL_SelfTest_SRAM(SRAM_RADECODE_DIAGNOSTICS, TRUE, &failInfoTCMRAM) always trigger the Interrupt function. Why? How can I avoid it ?

Best regard

Jeffer

  • Jeffer,

    Which device are you using?

    Are you getting an NMI interrupt?
  • Hi Anthony

    My device is RM48L520 and RM48L950.

    The function will trigger ESM Group2 10bit interrupt as below function.

    Because the phantomInterrupt() is empty, the ESM Group2 10bit error can be cleared and the program can move to the main(). But if I add some process in the interrupt, the program will stop and the program can't move to the main(). 

    Why the function will trigger the interrupt? Is that the RAM selftest mechanism? Is that normal? Is that means I can't add any process in the interrupt when the function is executed? 

    Another question, if I run the boolean SL_SelfTest_PBIST (register SL_SelfTestType testType, register uint32 ramGroup, register uint32 algoInfo). The RAM will be written some value. But the function address will also be covered. How the function can retrun to the normal list?

    By the way, I modify the startup from the Demo program of the Safety Library of RM48L950, and I modify the link.cmd. Run it in the RM48L530. Now I transfer the program from CCS to IAR. The problems are happened both in CCS and IAR, but the program in CCS is better. 

    Jeffer

    Best Regards.

  • Do you have a call to

    void SL_ESM_Init  ( ESM_Application_Callback  appCallback )

    In your code anywhere,  like the HalCoGen example has:

    This function will install the ESM interrupt handler into the VIM RAM.

    Probably you missed this and that's why it's going to the phantom.


    I don't really see where it's clearly documented that this step is needed but it would explain why you go to the phantom vector instead of the ESM interrupt handler.