• Answer Suggested

TMS570LC4357: Behavior of the TMS in case synchronous abort is detected while in abort handler

Part Number: TMS570LC4357

Hello,

I want to activate the ECC on caches on TMS570LC457 and for safety reasons I need to have fine control of the sanctions applied in case of uncorrectable errors so that to reach a safe state.

While reading the cortex-R5 TRM (ARM DDI 0460D) the last paragraph of section 3.8.4 about Abort handler indicates that in case a synchronous error occurs while in the abort handler then "the processor loops until the next interrupt" and "LR and SPSR values for the original abort are lost".

The first part of this sentence is not so clear in my mind and I'd like to confirm what the behavior of the TMS570LC4357 would be in the following case:

1. An abort exception is taken for any reason (synchronous or asynchronous abort)

2. Abort handler is entered and asynchronous aborts are automatically masked (CPSR.A set when entering IRQ/FIQ or Abort)

3. A synchronous abort occurs due to an ECC error when accessing cache

4. ??  What is the actual state of the processor and what will it perform, will it loop doing nothing waiting for a new interrupt and treat this interrupt as if not abort occurred at all ??

I am already aware that avoiding step 2. by ensuring that non synchronous abort could occur (by setting the memory space used by the handler as non cacheable as an example) would solve my issue and the point of this question is really to help me understand what would happen in step 4.

Thanks,

  • Hello Franck,

    I am checking with one of our EMIF experts and will get back with you shortly.


    Apologies, Franck for the above response. I have gotten my threads crossed and posted the incorrect message regarding your question.

    In regard to your specific question about the asynchronous and synchronous aborts, the synchronous abort would overwrite the information in the fault status register and the asynchronous fault information would then be lost. This, of course, is subject to timing of when the fault occurs vs. when the content of the fault status register is read. If the fault occurs after the fault status register is read during processing of the asynchronous abort, the abort should fire again after exiting the initial abort if you ever leave the abort after such an asynchronous abort occurs ( I mention this since an asynchronous abort is general of the worst kind since it cannot be assigned to any specific element of the device and, therefore, would usually require the system respond with a safe state response or potentially reset of the device).

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

  • In reply to Chuck Davenport:

    Hello Chuck,

    Thanks for the feedback. So if I understand well your answer in case the abort handler (entered because of a synchronous or asynchronous abort) generates a synchronous abort condition (as an example due to an non correctable ECC in cache for a data access), the expected behavior would be as follows

    1. abort handler  will continue its execution, without being interrupted on the instruction causing the synchronous abort condition

    2. FSRs will be overwritten with synchronous abort information

    3. Upon abort handler return, an abort should fire again to deal with the synchronous abort

    Such a behavior associated to the assumption that any asynchronous abort or synchronous abort in critical context (such as abort handler) shall be associated to a fatal sanction would then turn the ARM recommendation to have the abort handler in non cacheable external memory non mandatory.

    However for point 1. I do not really get how the handler could continue its execution if dependent on a data access for which an non correctable ECC error is detected. Would it continue bypassing the cache by forcing a miss, would it continue with a corrupted data value ? 

    Then regarding point 2. what about LR and SPSR which are mentioned as lost as well in the ARM TRM?

    Thanks,

  • In reply to Franck WARTEL:

    He Franck,

    It's been a while since we discussed this. I will review and come back once I re-review the thread and the discussion.

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

  • In reply to Franck WARTEL:

    Frank,

    I do see your points with respect to my earlier comments on continuance of execution. If there is an uncorrectable error during the execution of the abort handler, then what would happen? As you have stated, this should result in a synchronous abort which would hypothetically impact the content of the FSR and potentially affect the program flow of the abort handler. Realistically, I think this is a question we need to defer to ARM about since it involves some fairly low level operation of the CPU. I will check with them on this and come back to you. 

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

  • In reply to Chuck Davenport:

    Chuck,

    Isnt' an uncorrectable error in the exception vector what livelock is for:

    "Processor livelock because of hard errors or exception at exception vector." ?
    Best Regards,
    Anthony Seely

    If my reply answers your question please click on the green button "Verify Answer".

  • In reply to Anthony F. Seely:

    Hello Frank,

    As with your other question, I have exhausted my resources here at TI trying to get an answer on this question so I will reach out to ARM to get more clarity on the expected behavior.

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

  • In reply to Franck WARTEL:

    Hello Frank,

    Below is the response from ARM support regarding this scenario.

    "You are correct. If the core does not push LR_abt and SPSR_abt onto the stack inside the Data abort exception handler before another Data abort (synchronous or asynchronous) the "nested" abort will cause the core to lose the original state and return address.

    In your specific example above, the core will loop by continuously taking a data abort exception. The address of the LR_abt will be inside of the Data abort handler and not indicative of where the original exception occurred. You will effectively lose the ability to return to the background application."

    Thanks and Regards,

    Chuck Davenport


    If this response answers your question, please indicate it by verifying the suggested answer when provided.

  • In reply to Chuck Davenport:

    Hi Chuck,

    Thanks for your efforts to answer my question.

    Topic closed.

    Regards

    Franck