2414456_en-US

是

How to trigger different reset events on S32K3 for verification

Is there a recommended way to trigger each reset source on the evaluation board for verification purposes?

For example:

DEBUG_DEST

SW_DEST

HSE_SNVS_RST

......

I want to know all bits corresponding to the register DES & FES

Re: How to trigger different reset events on S32K3 for verification

It is a bit tricky question. There is no direct injection mechanism for these reset events, and we do not have any dedicated testing code or scripts we could provide — with the exception of the SAF/eMCEM API covering the FCCU portions. That said, I looked into the possible options and the following are the sketched methods that should work in practice.

Reset events on S32K3 fall into two categories based on how they can be triggered for verification — software-injectable and hardware-only — split across the two MC_RGM status registers, DES and FES.

Software-injectable resets can be triggered directly from code:

Direct SW commands — write MC_ME.MODE_CONF with DEST_RST or FUNC_RST and trigger MODE_UPD, maps to DES[SW_DEST] or FES[SW_FUNC] respectively
Watchdog expiry — stop the SWT service loop to trigger a functional reset on each timeout, incrementing FREC; once FREC reaches FRET the next reset escalates to destructive and sets DES[MC_RGM_FRE]
FCCU fault injection — use eMcem_InjectFault() or the FNCFC fake fault register to trigger functional or destructive reactions depending on NCF channel configuration; injecting a fault not in the configured NCF set specifically triggers the FOSU destructive reset path
CMU threshold manipulation — write CMU_FC_x.LTCR/HTCR outside the actual running frequency to produce a CMU frequency fault reset, with reaction type (functional or destructive) controlled through DCM configuration

Hardware-only resets require physical stimulation and have no software injection path:

STCU_URF requires a PLL loss-of-lock to occur during a live LBIST or MBIST sequence
HSE_TMPR_RST and HSE_SNVS_RST are security tamper events — intentionally not injectable via software as they protect cryptographic material
FXOSC_FAIL, PLL_LOL, and the LVD flags require disturbing the crystal, PLL dividers, or supply rails at the hardware level