Device: S32K312
Toolchain: Green Hills ELXR (compiler)
HSE Firmware: s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin
Debugger: Lauterbach TRACE32
Software: AUTOSAR RTD-based Bootloader (FBL) + Application (APP), two-image structure
ISSUE SUMMARY
On a subset of production units, the CPU hangs immediately after a Functional
(software) reset. The same units always boot correctly after a Destructive
(power-on) reset. The hang does not reproduce on our reference/known-good units.
EVIDENCE THAT AN NMI OCCURS BEFORE ANY APPLICATION CODE EXECUTES
1) CPU context captured at the hang point (auto-stacked exception frame):
- R0-R3 = 0x00000000, R12 = 0x00000000
- LR = 0xFFFFFFFF (reset default -> no BL has executed yet)
- PC = 0x00416904 (the very first instruction address of our Reset_Handler)
- xPSR = 0x01000000
2) SCB->ICSR = 0x00000802
- VECTACTIVE[8:0] = 2 -> NMI is the currently active exception
- RETTOBASE = 1
This confirms the CPU is currently executing inside the NMI handler.
3) Our vector table entry for the NMI offset correctly points to our own
default exception handler, so this is a genuine NMI event, not vector
table corruption.
REGISTERS CHECKED AT THE SAME HANG STATE (all read as clean / inactive)
- MC_RGM_DES = 0x00000000 (not a destructive reset)
- MC_RGM_FES = 0x20000000 (bit 29 only) (only "software functional reset"
flag set, no other functional
reset source flagged)
- FCCU: STAT, N2AF_STATUS, A2FF_STATUS, N2FF_STATUS, NCF_S0, IRQ_STAT
all = 0x00000000
- CMU_FC instances 0, 3, 4: SR = 0x00000000 (no frequency high/low fault)
- PMC LVSC = 0x00000000 (no LVD/HVD flag, latched or live)
- ERM (0x4025C000): could not be read on either good or failing units
(likely clock-gated in our configuration), so ERM status is unverified.
QUESTIONS
1. Are there any NMI sources -- other than FCCU / CMU_FC / PMC / MC_RGM --
that could fire before the application's Reset_Handler executes its
first instruction?
2. Since the HSE subsystem runs independently of the application core, is
it possible for an application-core Functional reset (which does not
reset HSE) to create a state mismatch that triggers an NMI on the
application core?
3. Is there a known errata for S32K312 matching this symptom (NMI only on
functional/software reset, never on power-on reset)?
Any guidance on additional registers to check, or documentation covering
NMI sources outside FCCU / ERM / CMU_FC / PMC, would be greatly appreciated.
Hi @Chibeom,
Could you please read registers MU_0.MUB CSSR0 and MU_1.MUB CSSR0 at the hang state, and confirm whether bit 0 (NMIC) is set in either of them?
Thank you
Hi @danielmartynek ,
Thank you for pointing us to MU_0.MUB / MU_1.MUB CSSR0.
CSSR0 (bit 0, NMIC) on both MU_0.MUB and MU_1.MUB reads 0x00000000 on the
failing unit at the hang state, so the MU->NMI request path (CCR0[NMI] /
CSSR0[NMIC]) does not appear to be pending.
However, while comparing MU registers between a known-good unit and a
failing unit (both captured at the identical hang-state address range),
we found a consistent difference:
Good unit Failing unit
MU_0.MUB VER 0x0300000F 0x0300000F (identical)
MU_0.MUB PAR 0x20200404 0x20200404 (identical)
MU_0.MUB CR 0x00000000 0x00000000 (identical)
MU_0.MUB SR 0x00000000 0x00000002 <- MURIP set
MU_1.MUB VER/PAR/CR: identical between good and failing units
MU_1.MUB SR 0x00000000 0x00000002 <- MURIP set
So on BOTH MU instances, SR bit 1 (MURIP) is set only on the failing
unit, consistently. Per the reference manual, MURIP indicates that
"processor A" has issued an MU reset, and can only be cleared by a
system reset (not by an MU reset).
Since the CPU is frozen inside the NMI handler before executing any
application code, it could not have cleared this flag itself, so it
must have been set prior to (or as part of) this boot sequence.
We'd appreciate your input on the following:
1. For MU_0.MUB and MU_1.MUB, which processor is "processor A" (i.e.
who sets MURIP)? Our header only exposes the "MUB" register block at
the application-core-accessible address -- does this imply the
application core is always "processor B" and HSE is "processor A"
for these instances?
2. Does "system reset" (required to clear MURIP) include a Functional/SW
reset of the application core, or only a Destructive/POR reset? If
MURIP is not cleared by our functional reset, that would explain why
it stays set across SW reset while it is clear after power-on.
3. Independent of the NMI question: is a set/stuck MURIP flag itself
expected or considered anomalous during normal operation?
4. Since CSSR0[NMIC] currently reads 0, is it possible for hardware to
auto-clear NMIC upon NMI exception entry, or does it only clear via
an explicit software write (in which case NMIC=0 would mean the
MU->NMI channel was never asserted in the first place)?
Thanks again for your help so far.
Hi @Chibeom,
I'm sorry for the delay. I was out of office for two days.
1. Yes, the HSE_B core controls the MUA interfaces of MU_0 and MU_1.
2. Any system reset should reset MURIP.
3. I would consider this an anomaly, as I do not have much information about it.
4. It requires an explicit write, as it is a W1C register.
Can you make sure that HSE_B is inactive at the time the functional reset is triggered?
Also, what is the state of HSE_B while the application is stuck in the NMI handler?
Can you read the standard HSE GPR (0x4039_C028), FSR, and GSR registers on the MU_0 B side?
Do you use the NMI pin in the application?
Regards,
Daniel
Hi Daniel,
Please find three combined register-dump screenshots attached, followed
by our findings organized by your questions.
--------------------------------------------------------
ATTACHMENTS
--------------------------------------------------------
Attachment 1: GOOD unit (Secure Debug enabled, running normally)
Attachment 2: FAILING unit, immediately BEFORE the functional reset is
triggered (normal operation)
Attachment 3: FAILING unit, AFTER the functional reset, stuck in the
NMI handler (hang state)
--------------------------------------------------------
FINDINGS
1) HSE_B activity at the time the functional reset is triggered, and
2) state of HSE_B while stuck in the NMI handler:
Comparing Attachment 2 (before reset) and Attachment 3 (after reset,
hang state) on the failing unit, every register we checked reads
IDENTICALLY before and after the reset:
- MU_0.MUB / MU_1.MUB TSR = 0x0000000F, RSR = 0x00000000 (no pending
messages on transmit/receive channels, unchanged by the reset)
- MU_0.MUB GSR = 0x00000000 (unchanged)
- MU_0.MUB FSR = 0x03600000 (unchanged)
- HSE GPR (0x4039C028) = 0x000001C1 (unchanged)
- MU_0.MUB / MU_1.MUB SR bit 1 (MURIP) = 0x00000002 -- already set
BEFORE the reset is triggered, and remains set, unchanged, after
the reset
So MURIP was already set prior to this reset cycle, and the
functional reset itself does not change any of these HSE-related
registers.
For reference, on a good unit with the same Secure Debug
configuration (Attachment 1), MURIP reads 0x00000000 on both
MU_0.MUB and MU_1.MUB, while HSE GPR and WKPU NCR read the same
values as the failing unit.
3) Regarding whether a set/stuck MURIP is anomalous:
Understood, thank you for confirming.
4) NMI pin usage:
We do not use the WKPU-routed NMI path (WKPU_IP_USED is not enabled;
no WKPU driver code is compiled into either our bootloader or
application image). WKPU NCR (0x402B4008) = 0x60000000 identically
across all three attachments. NSR = 0x00000000 in all cases. Since
this is unchanged across all units and conditions, we don't believe
an external/WKPU-routed NMI source is involved.
SUMMARY OF FINDINGS SO FAR
MURIP (MU_0.MUB and MU_1.MUB SR bit 1) is already set on the failing
unit BEFORE the functional reset is even triggered, and remains
unchanged throughout the hang. It reads 0 on a good unit with the same
Secure Debug configuration. This is the only consistent, reproducible
difference we have found across every register we've compared (FCCU,
CMU_FC, PMC, WKPU, and MU CSSR0/GSR/TSR/RSR/GPR/FSR).
Since MURIP is set by "processor A" (HSE_B) and should be cleared by
"any system reset" per your answer, and since it is already set before
our functional reset is triggered (and the reset itself does not appear
to change it), this suggests HSE_B issued an MU reset at some earlier
point that was never cleared by a "system reset" recognized by HSE_B.
QUESTIONS
1. Is there a way to determine, from the HSE side, what would cause
HSE_B (processor A) to issue an MU reset in the first place? We'd
like to understand why MURIP gets set at all.
2. Is there a recommended way for us to trigger a reset that HSE_B
recognizes as a "system reset" (to clear MURIP) from application
software, short of a full power cycle?
3. Could a stuck MURIP flag on the application-core side be related to
the NMI we are observing, or are these more likely two independent
symptoms of the same earlier event?
Thanks again for your continued help with this.
Hello @Chibeom,
Thank you for the detailed register dumps. I have escalated the questions around MURIP behavior and the potential NMI path between HSE_B and CM7_0 to our internal HSE team, as this seems to be not documented. I will get back to you once I have their input.