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.
