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.

About diagnostic method of ESM (Error Signaling Module) function.

Other Parts Discussed in Thread: TMS570LS3137

I currently use TMS570LS3137.

I am coding a program to diagnose that "Error Signaling Module (ESM)" function is functioning normally.
(Reference document = "Safety Manual for TMS 570LS31x and TMS570L21x Hercules ARM-Based Safety Critical Microcontrollers User's Guide")

In order to judge that the ESM is operating properly, what kind of "system information" needs to be read and judged?

  • Hi,
    I'm not too clear about your question as far as what system information to read.
    You can intentionally create some errors (e.g. a single-bit ECC error). The error event will be routed to the ESM as a group 1 (channel 26 or 28) error. You can configure the ESM so that it generates an interrupt to the VIM module. In the VIM module you can enable the channel (channel 20) for the ESM interrupt to generate the interrupt to the CPU. This is what you will do for ESM2A/ESM2B tests.
  • Hi,Charles.

    Thank you your answer.

    >> This is what you will do for ESM2A/ESM2B tests.

    I understand that you can artificially insert several failures. We decide which failure to intentionally insert.
    Then, if this "intentional fault insertion" is detected on the program, will it prove that the ESM-module itself is not broken?

    Best Regards.
  • Hi,
    Yes. If you implement the ESM2A/ESM2B diagnostics it means it is checking the below features of the ESM:

    1. Whether or not the ESM is able to capture the error signal. I suggested using RAM single bit error as an error input for the ESM.
    2. Whether or not the the masking is properly done. By default, the ESM group1 is not enabled for interrupting. If you write to the ESM to enable the channel corresponding to the RAM single bit error then it means the masking and the register writing is proper.
    3. Whether or not the interrupt request is generated properly to the VIM. The ESM needs to send an interrupt request to the VIM so that the VIM can generate the final IRQ request to the CPU.
    4. In the VIM, you again need to enable the channel associated with the ESM low level interrupt request.
    5. The VIM needs to generate the final IRQ to the CPU.
    6. Whether or not the CPU is taking the IRQ exception.

    The above is not a complete list of things the ESM2A/ESM2B will check as part of the Boot/Periodic SW test of error path reporting. But you should be able to see that the full path of the error path reporting is getting checked out. Using SRAM single bit error is one possible error source. You can try other sources for GP1 such as parity error from peripheral memories. You can also use double-bit ECC error from the RAM so the ESM Group 2 is tested.
  • Hello,

    Thank you for answering.

    Wrote,
    >>I suggested using RAM single bit error as an error input for the ESM.

    I appreciate the implementation suggestions.
    Implement the "RAM single bit error" for diagnose ESM2A / ESM2B based on the suggested content.
    By this implementation I understood that I can check 1 to 6 actions.

    >>Using SRAM single bit error is one possible error source.

    Does this mean that there is a possibility that an unexpected error may occur if the proposed "RAM single bit error" is implemented?

    Best Regards,

    Sazabi
  • Hi Sasabi,
    I don't understand why you meant that there is a possibility of an unexpected error? When I said the SRAM single bit error is one possible error source, i meant to suggest that you can also use other error sources to check ESM2A/ESM2B. For example, you can inject parity error into the VIM RAM, MibSPI RAM, DCAN RAM or etc, please look up the ESM error sources) to exercise ESM2.