• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 449 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RM44L520: can the interrupt of application be conflict with esm?

Sung-IL
Mastermind 31120 points
Part Number: RM44L520
Other Parts Discussed in Thread: RM44L920

Dear Champs,

My customer is curious if there is any possibility to make conflict between our diagnostic library and the interrupts of their application, and has several additional questions.

1. In SL_RM44L920_NoOS sample code, they want to check if the interrupts generated by diagnostic library functions can impact on their application, and they are worrying their interrupts can be pended so long time by  below interrupts generated by diagnostic library functions. Could you please check this? Do you have any information the interrupt latency caused by diagnostic library?

retVal  = Reg_Read_Compare(VIM,COMPARE);

retVal = SL_SelfTest_GIO(GIO_ANALOG_LOOPBACK_TEST, SL_GIOPORTA, 5U);

retVal = SL_SelfTest_SPI(SPI_ANALOG_LOOPBACK_TEST,SL_SPI2);

2. They found several 'loops' with below comments in the SL_RM44L920_NoOS sample code, and is curious if below test loops should be run periodically.

 /*running all posible 2 port algorithms on 2 port momories*/

/*running all posible 1 port algorithms on 1 port momories*/

/*running pbist on all ROM memories*/

/*running open slice algos  on memories*/

/*running pmos open algo on all  memories*/

3. Even after test done, my customer is curious why each I/O ports and functions would be initialized again. Is this for the testing during IDLE task?

    /* disable htu */
        sl_htuREG1->GC &= (uint32)(~0x10000u);
#if !(defined(_RM42x_) || defined(_TMS570LS04x_))
        sl_htuREG2->GC &= (uint32)(~0x10000u);
#endif

        /* Enable parity on selected RAMs */
        enableParity();

#if !(defined(_RM42x_) || defined(_TMS570LS04x_))

        memoryInit( (uint32)((uint32)1U << 1U)    /* DMA RAM */
                  | (uint32)((uint32)1U << 5U)    /* CAN1 RAM */
                  | (uint32)((uint32)1U << 6U)    /* CAN2 RAM */
                  | (uint32)((uint32)1U << 10U)   /* CAN3 RAM */
                  | (uint32)((uint32)1U << 8U)    /* ADC1 RAM */
                  | (uint32)((uint32)1U << 14U)   /* ADC2 RAM */
                  | (uint32)((uint32)1U << 3U)    /* HET1 RAM */
                  | (uint32)((uint32)1U << 4U)    /* HTU1 RAM */
                  | (uint32)((uint32)1U << 15U)   /* HET2 RAM */
                  | (uint32)((uint32)1U << 16U)   /* HTU2 RAM */
                  );

#else
        memoryInit((uint32)((uint32)1U << 5U)    /* CAN1 RAM */
                  | (uint32)((uint32)1U << 6U)    /* CAN2 RAM */
                  | (uint32)((uint32)1U << 8U)    /* ADC1 RAM */
                  | (uint32)((uint32)1U << 3U)    /* HET1 RAM */
                  | (uint32)((uint32)1U << 4U)    /* HTU1 RAM */
                  );
#endif

        /*Enable HTU*/
        sl_htuREG1->GC |= (uint32)0x10000u;
#if !(defined(_RM42x_) || defined(_TMS570LS04x_))
        sl_htuREG2->GC |= (uint32)0x10000u;
#endif
     mibspiInit();
     canInit();
  spiInit();

 

Their Safety diagnostic library version is 2.4.0.

Thanks and Best Regards,

SI.

  • 0
    TI__Guru**** 198766 points
    Sung-IL said:
    SL_SelfTest_GIO(GIO_ANALOG_LOOPBACK_TEST, SL_GIOPORTA, 5U);

    The interrupt from GIOA port is disabled in this function. This function will delay the GIOA interrupt.

    Sung-IL said:
    SL_SelfTest_SPI(SPI_ANALOG_LOOPBACK_TEST,SL_SPI2);

    This function disables the interrupt from SPI2 port. The interrupt from SPI2 will be delayed.

    All other interrupts for example from CAN or SCI should not be affected.

  • 0 in reply to QJ Wang
    TI__Mastermind 31120 points

    Hi QJ,

    Thanks for your response.

    Should all loops be run periodically? or should it be run depend on customer's usecase?

    Thanks and Best Regards,

    SI.

  • 0 in reply to QJ Wang
    TI__Guru**** 198766 points
    Sung-IL said:
    2. They found several 'loops' with below comments in the SL_RM44L920_NoOS sample code, and is curious if below test loops should be run periodically.

    The PBIST can be executed periodically.

    Sung-IL said:
    3. Even after test done, my customer is curious why each I/O ports and functions would be initialized again. Is this for the testing during IDLE task?

    The peripheral rams should be initialized after after pbist test. I don't think the I/O ports re-initialization is required. 

  • 0 in reply to QJ Wang
    TI__Mastermind 31120 points
    QJ Wang said:
    The PBIST can be executed periodically.

    Then, PBIST don't need to be executed periodically and customer should decide if it will be executed periodically or not, right?

    I think customer should decide if All functions in the sample code should be run or not per their usecase, right? e.g. what I mean that this is just example code and customer should implement their usecase by referring it, right?

  • +1 in reply to Sung-IL
    TI__Guru**** 198766 points

    I recommend performing PBSIT test for all the memories used in your application during boot-time. Running PBIST on memories is destructive and you should backup your data and runtime information when performing a PBIST periodically. 

    If your application has a very long ON time (Days, weeks, even years) without a power cycle, latent faults become an issue since. In this case, there may be a need to include the concept of a maintenance cycle where the unit is power cycled or soft reset at a regular, specified interval in time (once/wk, once/year... depends on the application needs). This interval could also, arguably, be considered a periodic test.