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.

TMS570LS1224: Handling Aborts/Illegal op by forcing nERROR to be asserted

Part Number: TMS570LS1224

Project hardware: TMS570 combined with the TPS65381:
[TPS:NRES]=>[TMS:nPORRST]
[TMS:nERROR]=>[TPS:ERROR/WDI]

In order to handle Aborts (Prefetch and Data), illegal instruction and other serious events, we are considering forcing a reset of the TPS, and hence the TMS, by forcing [TMS:nERROR] to be asserted; what is the best way to achieve this?

The TRM section 12.2.3 "Forcing an Error Condition" suggests that nERROR can be set low (asserted) via the ESM Error Key Register (ESMEKR) but this section implies that this is intended to allow testing of the nERROR functionality, with the implication that this technique may possibly be not suitable for the use I wish to put it.

Questions:

  1. Can ESMEKR be used to handle the Aborts etc. as described above?
  2. Is there a better way to handle abort?

Marcus

  • Hi Marcus,

    Aborts are usually unintended exceptions due to invalid or unsuccessful access of memory. Some of the causes for aborts are as follows:

    1. Permission fault indicated by the MPU
    2. Error detected in the data by the ECC checking logic

    When an abort happens, the program gets halted at the Exception Vector Table.

    The abort generated since #2 (uncorrectable ECC error) will assert ESM nERROR too. If nERROR pin is connected to TPS WERRO/WDI, the TPS will reset TMS570 if nERROR is asserted. 

    When accessing an implemented memory, I am not sure if the reset is necessary. 

  • Hi QJ, thanks for the update.

    RE:

    When an abort happens, the program gets halted at the Exception Vector Table.

    Yes, I know and it was based on this understanding that a possible plan was that the handlers "installed" in the Exception Vector Table, would assert nERROR via ESMEKR but unfortunately it is this aspect of my original question that I don't think is covered by your reply.

    I also appreciate that some Aborts do also affect the ESM and hence automatically result in nERROR assertion but this is not the case for all scenarios and, in addition, the plan was to use the same ESMEKR technique to handle faults for which there is definitely no automatic assertion of nERROR, such as errors reported by the RTOS.

    Two questions related to the above:

    1. What is your opinion re use of ESMEKR as described above?
    2. An alternative, would be to dispense with nERROR and instead connect a TMS GIO pin to the TPS [ERROR/WDI] pin so that it can entirely controlled the TMS software; what is your opinion of this method?

    Marcus

  • Hi Marcus,

    I prefer your second option to using ESMEKR.

  • Hi QJ, thanks for the update.

    Marcus