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

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).

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,

Hello , any news ?

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.

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. 

Chuck,

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

"Processor livelock because of hard errors or exception at exception vector." ?

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.

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."