S32K344 DCMROD3 unexpectedly clears after FCCU functional reset

[andye]

Hello,

I am hitting an issue where it appears the DCMROD3 GPR is being cleared by FCCU functional reset. This does not match my understanding that the DCMRODx registers are only cleared by destructive resets. Unfortunately, this means it's not possible to determine the cause of the FCCU functional reset after the reset occurs.

My goal is to inject a FCCU lockstep fault (FCCU NCF0, EIM channel 27) with the FCCU functional reset response enabled, then observe that bits 3 and 4 of DCMROD3 are set after the subsequent reset completes. I have used the FCCU configuration procedure to enable the functional reset response on NCF0 (NCFS_CFG0[1:0]=01b) and enable the NCF0 fault channel (NCFG_E0[0]=1). To avoid a FOSU destructive reset, I have also left the ALARM response enabled, left the ALARM timeout at its default (which is already less than the FOSU timeout), and set IRQ_ALARM_EN0[0]. I clear the RGM DES and FES registers (by writing 0xFFFFFFFF) to clean-slate the reset status, and then I inject the fault using EIM channel 27.

With this configuration, I can successfully inject the lockstep fault and see a functional reset. After the reset, DES=0 and FES=8, indicating FCCU_RST and no destructive resets. I also see NCF_S0[0]=1, indicating a NCF0 fault. This so far matches my expectations. However, DCMROD3=0 (reading at 0x402ac208). Shouldn't this show 0x18, for CM7_RCCU2_ALARM + CM7_RCCU1_ALARM?

If I disable the functional reset response ((NCFS_CFG0[1:0]=00b) and let software just keep running after the injected lockstep fault, then I do see DCMROD3=0x18. However, if I then issue a software functional reset via MODE_CONF=0x2 and the "Mode transition" procedure in section 47.5 of the reference manual, I see DES=0 and FES=0x20000000 (SW_FUNC) as expected, but DCMROD3=0.

This has led me to conclude that DCMROD3 is in fact cleared by functional resets, and not just destructive resets as its documentation implies.

How can I avoid DCMROD3 clearing after a functional reset? I want to be able to inspect what caused NCF0 post-reset.

Thank you!

[petervlna]

Hello,

I am hitting an issue where it appears the DCMROD3 GPR is being cleared by FCCU functional reset.

Actually, I think this is correct. As injecting fault via FCCU will only propagate the fault to FCCU status register and not backwards to the DCMROD3. So you can check the reaction of device on the fault once latched in FCCU.

But not the full fault propagation path from lock step error on RCCUs to the FCCU and so on.

So DCMR0D3 will not reflect this injection via FCCU, only if the real fault is created on the source module.

For more details see:

https://community.nxp.com/t5/S32K/S32K312-FCCU-Fault-Injection-Query/td-p/1754714

best regards,

Peter

[andye]

Hi Peter, thank you very much for the reply and the issue link. I read over that issue, and it looks like in that case, NCF 4 was being injected, and since the faults in NCF 4 have no EIM channels, the fault was injected using the SAF eMcem's DCMROD virtual error injection and the FCCU fake fault injection register (NCFF). With this technique for error injection, it makes sense to me that the error was invisible in the DCMRODx and was only visible in the FCCU.

But in my case, I'm injecting the lock-step fault with the EIM and not using NCFF. My understanding is that that should exercise the full chain as if an actual RCCU disagree occurred, because a true bit flip is being introduced in the core comparison. I do then see the physical DCMROD3 register show 0x18 as expected, provided I disable the FCCU's automatic functional reset response so that I get a chance to observe it. It's only after the next functional reset (that is, immediately if the FCCU functional reset response is enabled, or later if it is disabled and I create a functional reset manually after observing DCMROD3=0x18) that I see DCMROD3=0.

Thanks for the continued help!

[davidtosenovjan]

Have you tried to run your test without debugger? Which debugger you are using?

[andye]

Thank you for the suggestion. Unfortunately, the same thing occurs when the debugger (J-Link Plus) is physically disconnected.

I have a firmware loaded which accepts Ethernet commands to inject lockstep errors, and which also samples DCMROD3 early in the boot process and reports its value over Ethernet. With this setup, and having freshly power-cycled after disconnecting the debugger, I still see DCMROD3=0 reported after taking the FCCU-induced functional reset following the lockstep error injection.