I am currently configuring the FCCU and attempting to implement the recommended recovery mechanism for fault NCF[4] based on the NXP fault map document (Interrupt followed by SBC-initiated POR recovery initiated in the interrupt service routine).
I am using the S32K312 microcontroller alongside the FS65 SBC. Could you please clarify if it is possible to issue a software reset to the FS65 SBC via SPI command from the controller to re-initialize all power rails? If so, could you advise on the correct implementation?
I attempted to enable the rstb bit in the SBC_FS65_FS_SF_OUTPUT_REQUEST_ADDR register, but I did not observe an SBC reset.
Please let me know how to properly implement this recovery mechanism.
BR Sandeep Singh
Hi Peter,
The recovery mechanism mentioned above is documented in NXP's Fault Map document, which is attached to the S32K3 Reference Manual (Rev 8, 01/2024).
Additionally, since the power supplies are built up by the SBC FS65 in our case which are used to power up MCU, resetting the MCU alone will not stabilize the power supplies generated by the SBC.
Best regards,
Sandeep Singh
Hello,
I am bit confused by the recommendation.
Interrupt followed by SBC-initiated POR recovery initiated in the interrupt service routine"
This recommended recovery mechanism does not appear technically valid to me.
NCF[4] represents voltage-monitor faults, including violations affecting the MCU core supply. Once the core voltage is outside its valid operating range, correct execution of the core, flash accesses, SRAM accesses, and the interrupt service routine itself can no longer be assumed. Therefore, relying on an ISR to establish SPI communication with the SBC and initiate recovery does not provide a trustworthy safety reaction.
Such faults should be handled through the hardware safety path:
PMC → FCCU → MC_RGM → reset
This corresponds to an R3 FCCU reaction, which is entirely hardware-based and initiates a chip functional reset without relying on software execution. The S32K3 Safety Manual describes exactly this behavior for R3 faults.
Unless there is an undocumented mechanism or a guaranteed early-warning voltage threshold that explicitly ensures valid MCU execution for the complete ISR and SPI transaction, the proposed interrupt-based recovery is not justified from an architectural or functional-safety perspective.
Could you please provide the exact document and revision that requires NCF[4] to be handled by an interrupt followed by an SBC-initiated POR, together with the architectural assumption guaranteeing valid software execution after the voltage violation?
Until this is clarified, I would not recommend implementing the recovery through an interrupt.
Best regards,
Peter
Hello,
The recovery mechanism mentioned above is documented in NXP's Fault Map document, which is attached to the S32K3 Reference Manual (Rev 8, 01/2024).
Ok, it is just recommendation. I will in no cases use that in safety critical systems.
Additionally, since the power supplies are built up by the SBC FS65 in our case which are used to power up MCU, resetting the MCU alone will not stabilize the power supplies generated by the SBC.
It will not stabilize, but reseting will put MCU in the safe state. So no potentially corrupted instruction are executed.
If you have one time event in power supply (like inductance due to weak shielding) then SBC will still supply MCU with correct voltage, but the MCU execution is compromised. Therefore calling reset from interrupt makes no sense to me.
Update:
Ok, I was consulting this issue with safety team.
And the NCF[4] is called in case of overvoltage, or low voltalge warning on low power rail.
In case of voltage drop the POR (power on reset) is executed.
LVD (Low Voltage Detect)-> warning -> interrupt
LVR (Low Voltage Reset)-> POR
HVD -> notification -> FCCU NCF4
Overvoltage / Go-Nogo faults propagate via FCCU NCF4.
LVD is an early-warning notification.
LVR bypasses FCCU entirely and goes directly to POR.
Best regards,
Peter