S32R294 The FCCU functional reset will always cause a SWT0 reset

[syzbrink]

After configuring the FCCU, I tried to trigger a long functional reset by modifying the NCFF register. The NCFF can successfully trigger the alarm interrupt and the reset. However, after the reset is done, I check the RGM register to figure out the reset reason and it shows SWT0 reset. Why is that?

During all the process, the lauterbatch is connected.

The boot config word in IVT is set to disable the SWT0, also in startup code, I disabled the SWT0.

    ASM_KEYWORD(" e_lis     r6,0xFC05 ");

    ASM_KEYWORD(" e_or2i    r6,0x0010 ");

    ASM_KEYWORD(" e_li      r7,0xC520 ");

    ASM_KEYWORD(" se_stw    r7,0x0(r6)");

    ASM_KEYWORD(" e_li      r7,0xD928 ");

    ASM_KEYWORD(" se_stw    r7,0x0(r6)"); /* # Disengage soft-lock */

    ASM_KEYWORD(" e_lis     r6,0xFC05 ");

    ASM_KEYWORD(" e_or2i    r6,0x0000 ");

    ASM_KEYWORD(" e_lis     r7,0xFF00 ");

    ASM_KEYWORD(" e_or2i    r7,0x010A ");

    ASM_KEYWORD(" se_stw    r7,0x0(r6) "); /* # WEN = 0 */

By the way, if I set boot config word in IVT not to disable the SWT0, the system can still run without reset after POR, so I think the diasble in startup code works.

[petervlna]

Hello,

I will try that. But I am still confused why is that power up reset will not cause a SWT0 reset if there is something wrong during the SW init process. What is the difference between power up reset and long functuinal reset? Do long functuinal reset has other process such as selftest?

The power on reset is always different from other sources of reset. Various initialization are done only on power on reset. But here, I think your device SW will branch based on the reset type and I expect in that branch you dont take a care about SWT. At least this makes sense to me.

Exclude all the SW you have not 100% control / knowledge on its low level. Or do debugging, I am quite sure some SW is enabling SWT0 which is causing the reset. RGM just report reset cause, in this case it is hardwired signal from SWT to RGM.

As you can see POR is much longer then other resets.

I draw this some time ago and it generally applied for all PowerPC devices. So you can see after power on reset in reset PHASE0 is analog modules initialization.

Best regards,

Peter

[petervlna]

Hello,

During all the process, the lauterbatch is connected.

Well, during reset debugger is not connected. I do not know how you read the RGM. Do you have routine to read it in your startup and store its value to NVM? Or do you use some debugger script to halt core on reset exit?

The boot config word in IVT is set to disable the SWT0, also in startup code, I disabled the SWT0.

If that is the case then SWT0 must be disabled. But apparently you see SWT0 reset in RGM, so the SWT0 has timeout. (this is HW routing of SWT0 to RGM)

I guess you are using some large SW with many drivers. Maybe some SW conditional branching is causing this.

I suggest you to erase micro and write small program just to do FCCU reset and SWT0 disable and you will see that the SWT0 stays disabled.

Furthermore APTIV has direct support from NXP via FAE, I wonder why you are not using it.

Best regards,

Peter

[syzbrink]

Hello

Thanks for replying!!!

Well, during reset debugger is not connected. I do not know how you read the RGM. Do you have routine to read it in your startup and store its value to NVM? Or do you use some debugger script to halt core on reset exit?

I will read the RGM on SW init and output it by CAN. But if the debugger is not connected, the RGM will show POR reset. I think that is caused by PMIC. This is consistent with what you said below, SW gets stuck during long functional reset. The debugger will disable the PMIC so it shows SWT0 reset.

I guess you are using some large SW with many drivers. Maybe some SW conditional branching is causing this.

I suggest you to erase micro and write small program just to do FCCU reset and SWT0 disable and you will see that the SWT0 stays disabled.

I will try that. But I am still confused why is that power up reset will not cause a SWT0 reset if there is something wrong during the SW init process. What is the difference between power up reset and long functuinal reset? Do long functuinal reset has other process such as selftest?

Furthermore APTIV has direct support from NXP via FAE, I wonder why you are not using it.

We tried, but it seems that they are not familiar with S32R294, and I found simliar cases here, so I came here for help.