Safety perspective of XRDC ISR vs. hard fault?

[RandyKrakora]

Customer is Ford.

s32g3

They have recently added a XRDC interrupts to their safety core ( M7_0 ), so now when their a53 ( linux ) cores try to access restricted memory, instead of seeing a hard fault in linux, they see the XRDC interrupt, which is what they would expect now. But, their question is, from a safety perspective, which is better? The XRDC ISR on the safety core? Or a hard fault in linux?

-Randy Krakora

[antoinedubois]

Hi Randy,

This is a good question. It depends on other constrains than safety but also the availability concept. Basically do they expect this type of fault to happens often due to the Linux (QM SW)? Do they want to implement retry strategy by initiator of the fault (Linux) or do they want to reduce availability and Reset Linux for any of this wrong access fault.

I prefer the ISR to the Safety Core + Bus error message on Linux. If the Bus error can be recovered within Linux by killing the faulty process, the availability of QM Application in Linux is increased. It can also allow to diagnose some event on the QM SW using Linux. If the ISR on Safety Core happens too many time (some type of counter needs to be implemented), the Safety core Reset Linux. The advantage is that you have a SW that is flexible available but monitored by Safety. 

Security also needs to be taken into account in term of access permissions.

I hope it helps