Part Number: TMS570LC4357
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.
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,
In reply to Chuck Davenport:
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?
In reply to Franck WARTEL:
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.
If my reply answers your question please click on the green button "Verify Answer".
In reply to Anthony F. Seely:
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.