Mcu_PerformReset and detecting Mcu_GetResetReason

[ola_gook]

SW32K3_RTD_4_4_2_0_0_D2203

S32K3X4EVB-Q257

Lauterbach T32 N.2022.03

My main objective is to perform a transition from application context to bootloader context. Doing so, I need to detect that the reset is not POR since I need to retain some RAM from appl context.

To accomplish this, I am trying to detect a functional reset at startup but am only getting MCU_POWER_ON_RESET using Mcu_GetResetReason. Don't understand why.

Added the following snippet of code to the S32DS Mcu Example for S32K344:

Mcu_DistributePllClock();

Mcu_SetMode(McuModeSettingConf_0);

mr = Mcu_GetResetReason();
if (mr != MCU_POWER_ON_RESET)while(1){}

Mcu_PerformReset();

if (Mcu_GetClockFrequency(FXOSC_CLK) != FXOSC_CLOCK_FREQ)
{
Exit_Example(FALSE);
}
else
{
Exit_Example(TRUE);
}

Expected result was that the PerformReset() function triggers a functional reset and that the Mcu_GetResetReason indicates this, causing the while(1) loop to NOT generate a new reset. However, what I see on the EVB is that the reset continually triggers, indicating the the while(1) loop is not executed (I expected this to be visible by not seeing more than one reset on the reset LED).

Also tried setting the destructive reset escalation setting in Mcu config to zero. No difference.

Furthermore, I cannot follow the reset using my Lauterbach debugger. Maybe there is a setting that allows me to do that, but I have not yet managed to find such a setting. I basically want the debugger to remain attached to the core while the reset takes place so that I can break execution after the reset. As of now, it just says that the cores are down, running(power down) and reset.

[VaneB]

Hi @ola_gook 

The procedure in chapter 30.8 System RAM retention across functional reset of the S32K3xx Reference Manual, Rev. 5, is performed by S32K3 internal hardware. So no software code is needed.

Functional resets will keep SRAM data unchanged by hardware mechanism.

Destructive resets cannot guarrantee the SRAM data integrity.

For the S32DS default startup code, the SRAM ECC initialization will be performed no matter what reset source it is. So the SRAM data is overwritten after each reset.

B.R.

VaneB

[ola_gook]

Thanks for the response.

The problem is however not the retention of SRAM, I already updated the S32DS startup code to handle this based on the reset type. The problem is that all resets performed using the RTD Mcu_PerformReset etc functions yields the same behaviour, i.e. indicating POR.

I guess that you are suggesting that I move my retention ciritcal RAM to the referred "retention RAM area", but I still think the APIs for detecting Reset reason should be usable for what I am trying to do.

Are you saying that functional resets are not possible to discern from power on resets during startup?

Or should I use another method for resetting the Mcu when I need to go to bootloader?

Is there example code for this?

Regards,

/Ola

[ola_gook]

Just realized my reply was not clear enough.

As you say, the SRAM is initiated in the startup code. Thus, any SRAM settings that need to be retained from "application level" will be overwritten.

The only way to avoid overwriting it in the start code is to detect that the reset reason was indeed a functional reset rather than a POR. Only in this case should the "application level" data be left untouched by the startup functions.

I don't see how I can accomplish this without knowing what caused the startup/reset.

Thanks.

[VaneB]

Hi @ola_gook 

I suggest that to detect the cause of the reset, check the values of the DES (Destructive Event Status Register) and FES (Functional / External Reset Status Register) registers of the MC RGM.
Please refer to section 32.8 MC_RGM register descriptions of the S32K3xx Reference Manual, Rev. 5.

[ola_gook]

Thank you for your response.

However. As I am using the RTD (realtime drivers provided by NXP) for both reset generation and checking reset source, this is already sufficiently encapsulated by the above mentioned functions Mcu_PerformReset and Mcu_GetResetReason. Diving into these functions, it is clear that they in fact check the DES and FES registers as suggested. The whole point of using the RTD is to stay high in abstraction.

Also, the EVB that I have referred in my original question is also an NXP product. Using an NXP RTD on and NXP evalboard, I would expect a more helpful answer.

Maybe you can defer this ticket to someone who is familiar with the RTD and/or EVB?

[lorePhoenix]

Hello @ola_gook, I have exactly the same problem you faced, did you find a possible solution? 

Thanks in advance.

[ola_gook]

I ended up defining a new retention area in RAM and changed the Init_table to exclude the retention part.

Next, I added a call to the aforementioned Mcu_GetResetReason to check for reset reason. If it indicates a destructive reset, I programmatically reset the retention part of the RAM.

Since I put the code in system.c (Start of SystemInit()), I could stay high in abstraction and use the RTD API.

Regards,

/Ola

[Pusoy]

https://community.nxp.com/t5/S32K/S32K344-reset-reason/m-p/1690729

I found the answers.