• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 510 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.

RM41L232: The error response action of some safety features not found in safeTI code

lina zhang
Intellectual 440 points
Part Number: RM41L232

Hello,

I am using SafeTI 2.3.1 on RM41L232 controller to realize our system.

From safety manual, We know that when error happens, [IOM3],[VIM1] and [ADC4] safety features will send signal to ESM,

individually corresponding to [Group1 Channel 37], [Group1 Channel 15] and [Group1 Channel 19].

But in sl.esm.c of SafeTI, we found that in the function esmGroup1Handler there weren't the revelant processings about  the above three error flags.

so that in our application we could not do any process in error callback function.

Is it necessary that we ourselves add the revelant process about  the above three error flag into  Sl_esm.c?

or these errors handlings are in other files? Please confirm and thanks first.

  • 0
    TI__Guru 59540 points

    Hello Lilly,

    Sorry for the delay in getting back to you on your questions.

    In version 2.3.1 of the SafeTI Diagnostic Library I see the following in the esmGroup1Handler call back function:

    For ESM Group 1 Channel 15:

    /** VIM Parity Error **/
        case ESM_G1ERR_VIMRAM_PARITY:

			if (TRUE == SL_FLAG_GET(VIM_SRAM_PARITY_TEST)) {
				cancelCallback  = TRUE;
				callbackCancelCount++;
			}
            /* Extract the parameters & clear the flag */
            callbkParam1 = SL_VIM_ADDERR;
            SL_VIM_PARFLG = 1u;
            break;

    For the MibADC ESM and IOMM errors, you are correct that the library doesn't seem to have these ESM errors included in the call back function. If you are planning to have interrupts assigned to these specific ESM errors, you would need to add them to the call back function.

    Note that there is a MIBADC Parity diagnostic test in the SL-SelfTest.c file. Search for "ADC_SRAM_PARITY_TEST"

    The more critical of these would be MIBADC Parity error in case there are faults in MIBADC memory they would need to be handled in some way applicable to your requirments. i.e., the data would be thrown out, some sort of retry mechanism or resampling would occur, collecting multiple samples or averaging, data range checking,  among other methods to handle the possible fault and subsequent notification.

    In regard to the IOMM fault, the ESM  GRP1 Channel 37 flag is set under the following two conditions:

    - Address Error – occurs when there is a read or a write access to an un-implemented memory location within the IOMM register frame. 

    - Protection Error – occurs when the CPU writes to an IOMM register while not in a privileged mode of operation.

    Either of these should be indicated in your debug and test of the device. If they occur during application run time, I would suspect there is some sort of spurious write by the CPU indicating a pointer error or soft error in the address of a write. In either case, there will be no impact to the IOMM as these accesses will be denied. It is really an indication of something else going wrong and should be handled according to your application requirements as any errant write or pointer access would be. Again, adding this to the call back function is up to you.