S32GのトピックRe: Questions Regarding Implementing Safety Mechanisms (Addendum_S32G2.xls) on S32G2 A53 Core

Questions Regarding Implementing Safety Mechanisms (Addendum_S32G2.xls) on S32G2 A53 Core

somemore — Fri, 13 Feb 2026 05:29:55 GMT

Hello NXP team,

I am currently working with S32G2 and implementing diagnostic tests on the A53 core (Application Processor).
For safety-related items, I am using the following documents:

sm793411 – S32G2xxx Safety Manual (1.1)
Addendum_S32G2.xls – Safety Mechanism List
S32G2 Reference Manual

While reviewing these materials, I found several points that I would like to clarify.

1. Safety Mechanisms Connected to FCCU (NCF) – Do I need additional SW diagnostic test code?

In Addendum_S32G2.xls, several safety mechanisms list a fault reaction routed to the FCCU NCF channel.
My understanding is that, for these items, the application software on the A53 core does not need to implement additional diagnostic test code, and the main tasks are:

Register configuration
FCCU reaction configuration
Enabling the related fault sources

Could you please confirm which official document explains the recommended configuration procedure?
Also, should this configuration be implemented through S32 Design Studio, or is there any other recommended workflow/tool?

2. Safety Mechanisms that Require Application-Level Diagnostic Software on A53

I want to understand which safety mechanisms must be implemented directly in A53 Application Software (i.e., not handled automatically by FCCU).
So far, I identified the following items:

SM4.STM.SWCHECK – Application checks and reports the STM timestamp progression
SM1.SWT – Application-level watchdog used for safety-related software health check
SM4.TIMESTAMP.APP_CHECK – Application monitors timestamp increment and reports error

Are there any additional safety mechanisms in Addendum_S32G2.xls that must be implemented directly by the A53 application?
(Again, scope is limited to A53 Application SW.)

3. FCCU Fault Source Documentation for S32G Series

For the MPC574xP series, there is a very helpful document:

AN5259 – MPC574xP FCCU Fault Sources

Is there a similar application note or document for the S32G family?
A consolidated list of FCCU fault sources for S32G would greatly help in understanding and implementing the safety mechanisms.

Thank you in advance for your support.
Any guidance or documentation references would be greatly appreciated.

Re: Questions Regarding Implementing Safety Mechanisms (Addendum_S32G2.xls) on S32G2 A53 Core

Bio_TICFSL — Wed, 18 Feb 2026 14:32:40 GMT

Hello,

It sounds like you are deep into the safety integration of the S32G2, which is no small feat. Transitioning from the MPC series to the S32G involves a shift toward more complex hardware-software interaction, especially with the ARM Cortex-A53 clusters.

Here is a breakdown of your points to help clarify the safety workflow.

1. Safety Mechanisms Connected to FCCU (NCF)

Your understanding is mostly correct. If a safety mechanism (SM) is purely hardware-based (e.g., ECC on a memory array) and its output is hard-wired to an FCCU Non-Critical Fault (NCF) channel, you do not need "diagnostic test code" to detect the failure.

However, the "Main Tasks" you listed are missing one critical phase: Safety Integrity Validation (Diagnostic Testing).

The Gap: While the hardware detects the fault, ISO 26262 often requires you to verify that the hardware detection logic itself is still functional (Latent Fault Metric). For many FCCU-mapped SMs, you may still need to periodically trigger a "Software Test Trigger" (if available for that IP) to ensure the path to the FCCU is alive.
Documentation: The official procedure is found in the S32G2 Safety Manual. Specifically, look for the section titled "Fault Control Unit (FCCU) Integration" and the "Safety Concept" chapter for each specific IP.
Workflow:
- Configuration: Usually handled via the S32 Configuration Tool (integrated into S32 Design Studio) or via the RTD (Real Time Drivers).
- Implementation: The RTD provides the Fccu_Ip driver, which is the recommended way to initialize the reactions and mapping rather than manual register poking.

2. SMs Requiring A53 Application-Level Software

Beyond the timestamp and watchdog items you identified, the A53 requires manual software implementation for mechanisms that the hardware cannot "see" logically. In the Addendum_S32G2.xls, look for these additional areas for the A53:

SM_A53_01 (Software Countermeasures for Common Cause Failures): Since the A53 cores often run in Performance Mode (not lockstep), the app must handle logical consistency checks if being used for ASIL functions.
MMU Management: Hardware provides the MMU, but the A53 Application SW must implement the table parity/error handling and periodic software-based memory protection checks.
Register Integrity: Some configuration registers for A53-specific peripherals (like the GIC or Generic Timer) require periodic software read-backs to ensure no "bit flips" have occurred in static configurations.
E2E (End-to-End) Protection: Any data coming from the A53 to the M7 or external communication must be protected by the application (CRC/Sequence Counters), as the FCCU cannot validate the "correctness" of your data payload.

3. FCCU Fault Source Documentation

The S32G series handles documentation differently than the older MPC series. There isn't a 1:1 "AN5259" equivalent, but the information is consolidated in a more "database-centric" way:

The Reference Manual (RM): Look at the FCCU Chapter. It contains the table of "Non-Critical Fault Channels." This is the direct equivalent of the list in AN5259.
The Safety Manual (SM): This is your primary source. It maps the Safety Mechanisms (SM_xxx) to the FCCU channels.
The Hardware-Software Interface (HSI): This is often provided as part of the SafeAssure package.

Document	Purpose for FCCU
S32G2 RM	Defines the physical mapping of NCF[x] to the hardware source.
S32G2 Safety Manual	Defines the "Safety Goal" and which NCF channel satisfies it.
RTD Documentation	Provides the API usage for the `Fccu_Ip` driver.

Comparison Summary

Feature	MPC574xP (Legacy)	S32G2 (Current)
Primary Doc	AN5259	S32G2 Safety Manual
Config Tool	EB Tresos / Manual	S32 Configuration Tool (RTD)
A53 Role	N/A (M4/Z4)	Complex (Requires MMU/Cache/Cluster SMs)

regards

Re: Questions Regarding Implementing Safety Mechanisms (Addendum_S32G2.xls) on S32G2 A53 Core

somemore — Thu, 19 Feb 2026 08:16:18 GMT

Hi Bio_TICFSL,
Thanks again for your detailed explanation — it was extremely helpful.
I have one additional question.
In the link below from the NXP community:
https://community.nxp.com/t5/SafeAssure-Community-Archived/Safety-Manual-Rev-7-Fault-Reaction/m-p/2101637?attachment-id=197792
I noticed that the S32K3xx family provides the document “S32K3xx Functional Safety Application Note”, which explains how Safety Mechanisms should be configured and what responsibilities the integrator must handle.
Is there a similar Application Note available for the S32Gxx family?
If such documentation exists but requires special access or permissions, could you please let me know. I will handle it.
Thanks again for your support!
Best regards,