Customer is Aurora.
s32g2
They are having trouble with a method to trigger a debug without needing to perform a reset first. So they are wondering if they even need to consider SM1.FCCU.UNINTENDED_DEBUG_MON?
It seems to me a debugger can be "attached" to a running system, so being able to detect this and force a fault to trigger a chip reset would be vital to safety? But they are indicating the test for this fault requires a chip reset, so it wouldn't be the same as a debugger "attach".
-Randy Krakora
Hi Randy,
I created a ticket. I doubt we would be able to change it for S32G however we will try to improve our future product.
Hi Randy,
Yes this is a key assumptions of the Safety concept to have this fault activated. The reason is for the freedom from interference. All the Debug logic in the SoC is really complex and really intrusive. Therefore it is developed QM (you can see the number of errata due to debug...). If any part of the debug logic is activated due to a random HW failure (not when a debugger is attached) the core will likely violate its safety goals, as it is a dependent failure between its functions and safety mechanisms (lockstep may not work correctly, watchdog may be impacted, configuration of safety related IP may changed).
That's why in the design all the low level debug signals are ORed together and connected to FCCU, if for any reason debug is activated, the assumptions is to go to safe state.
The Use Case that the application is running safety related application while the Debug is attached was not considered. It is usually done for prototyping therefore has a different Safety standard than ISO26262 (I forgot the name of this standard for Safety for testing on public road...).
Now it seems Aurora is also searching for a method to trigger the debug (for latent fault test I imagine). I agree this is a tricky one that we have been discussing at NXP. My current argument is that we do not need fault injection to prove the SM is working as there are multiple redundant path that would trigger it within the design. What I say may be contradicting the AoU in the Safety Manual, but it is currently in debate within the safety community and a conservative approach was taken.
Antoine,
Can we update any documentation stating the customers do not need to test for this fault?
I think that may be what Aurora is looking for here.
-Randy Krakora