S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention

Sharif417

Hello NXP Team,

I am working with an S32K312 Cortex-M7 using S32 Design Studio and AUTOSAR RTD 7.0.1 / AUTOSAR 4.9.

I am currently testing the MC_RGM reset behavior, particularly SWT0 functional reset, functional reset escalation, destructive reset, SRAM retention, SBAF/recovery behavior, and the Power IP reset APIs.

1. SWT0 functional reset escalation

I am using SWT0 timeout to generate functional resets.

My MC_RGM configuration is:

MC_RGM_FRET_FRET((uint32)15U),
MC_RGM_DRET_DRET((uint32)0U)

I observe the functional reset counter increasing:

SWT0 functional reset #1 -> FREC = 1
SWT0 functional reset #2 -> FREC = 2
...
SWT0 functional reset #14 -> FREC = 14

After the next SWT0 reset, FREC is cleared/reset, but I do not observe the expected:

DES[MC_RGM_FRE] = 1

My questions are:

Does SWT0_RST participate in the MC_RGM functional reset escalation counter (FREC) on S32K312?
When FREC reaches FRET = 15, should MC_RGM_FRE be generated and should DES[MC_RGM_FRE] be set?
What exact values should I expect for FES, DES, FREC, FRET, Power_Ip_GetResetReason() immediately after the escalation?
Is any additional configuration required for SWT0 to participate in FRET escalation?
Can SBAF/recovery handling interfere with FRET escalation?
Is there any known erratum or known S32K312 behavior related to SWT0/FRET escalation?
When I run the application continuously, after the 15th functional reset the application/debugger stops instead of allowing me to observe the expected destructive reset. I would like to know whether this is related to the reset sequence, SBAF recovery, or the debugger.

2. I want every SWT0 functional reset to become destructive

For testing purposes, I would also like to achieve:

SWT0 timeout
↓
Functional reset
↓
Immediate destructive reset

instead of waiting for 15 functional resets.

Can this be achieved by configuring:

FRET = 1U;

Specifically:

Does FRET = 1 cause the first qualifying SWT0 functional reset to escalate to a destructive reset?
Is any additional MC_RGM configuration required?
Is SWT0 guaranteed to be a qualifying source for this escalation?
Can SBAF/recovery behavior affect this?
Is this supported directly through RTD 7.0.1 configuration?
3. SRAM data is cleared after every functional reset

According to my understanding of the S32K3xx Reference Manual, SRAM/system memory should be preserved across a functional reset.

I created an SRAM test variable:

#define SRAM_TEST_ADDR ((volatile uint32_t *)0x204007d4U)

and use it to verify retention across functional resets.

However, I observe that the SRAM data is being cleared/re-written to zero after a functional reset.

My questions are:

Is SRAM preserved by the hardware during functional reset but overwritten afterward by software?
Which SRAM regions are guaranteed to retain their contents across functional reset on S32K312?
What is the recommended way to place a variable in SRAM so that its contents are retained across functional reset?
Should I use a dedicated .noinit or retained SRAM section?
Is there any specific MC_RGM/SRAM configuration required for retention?
What is the recommended RTD 7.0.1 method for retaining application data across functional reset?
4. Direct software destructive reset

I am also testing a direct software destructive reset using the Power IP:

Power_Ip_Init(&Power_Ip_HwIPsConfigPB);

gVar= Power_Ip_GetResetReason();

for (count = 0; count < 10125000; count++);

Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB);

My current MC_RGM configuration contains:

static const Power_Ip_MC_RGM_ConfigType Power_Ip_MC_RGM_ConfigPB =
{
(MCU_DEST_RESET),
...
MC_RGM_FRET_FRET((uint32)15U),
MC_RGM_DRET_DRET((uint32)0U)
};

The destructive reset occurs, but the debugger repeatedly loses and re-establishes communication.

I see messages such as:

INFO: DAP IDCODE = 0x6BA02477
INFO: DAP successfully powered up. DP CTRL/STAT = 0xF0000000

repeated multiple times, followed by:

Interrupt command received. Halting execution.

I would like to understand:

Is repeated DAP reconnection expected during a destructive reset?
What exactly happens to the Cortex-M7 during the destructive-reset sequence?
When does the CPU become available again after the destructive reset?
What is the recommended way to debug a single software destructive reset?
5. Breakpoint behavior before Power_Ip_PerformReset()

I cannot reliably hit a breakpoint immediately before:

Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB);

I added a delay before the API, expecting the debugger to have enough time to gain access.

Sometimes the breakpoint is only reached after I manually pause the target and then resume execution.

I would like to understand:

Why can the debugger miss the breakpoint even though there is a delay before the reset API?
Is this related to the target repeatedly resetting and the debugger reconnecting through DAP?
Is there a recommended method for catching the CPU immediately before or immediately after a destructive reset?
Is the RTD DISABLE_DEBUGGER_TRAP option relevant to this behavior?
6. Power IP initialization and Power_Ip_SetMode()

My RTD provides:

void Power_Ip_Init(
const Power_Ip_HwIPsConfigType *HwIPsConfigPtr);

void Power_Ip_SetMode(const Power_Ip_ModeConfigType *ModeConfigPtr);

void Power_Ip_PerformReset(
const Power_Ip_HwIPsConfigType *HwIPsConfigPtr
);

Power_Ip_ResetType Power_Ip_GetResetReason(void);

Power_Ip_RawResetType Power_Ip_GetResetRawValue(void);

I currently use:

Power_Ip_Init(&Power_Ip_HwIPsConfigPB);

and:

gVar = Power_Ip_GetResetReason();

My mode configuration is POWER_IP_RUN_MODE.

I would like clarification on:

Is Power_Ip_Init(&Power_Ip_HwIPsConfigPB) the correct initialization before using the Power IP reset APIs?
Is Power_Ip_SetMode() required for software functional/destructive reset testing?
Since my selected mode is POWER_IP_RUN_MODE, can Power_Ip_SetMode() be omitted for this reset test?
How should I configure separate software functional-reset and software destructive-reset configurations using RTD 7.0.1?

Environment
MCU: S32K312
Core: Cortex-M7
S32DS: S32 Design Studio
AUTOSAR: 4.9
RTD: 7.0.1
Reset source: SWT0
FRET: 15
DRET: 0

I can provide the complete test application, Power_Ip_PBcfg.c, linker configuration, MC_RGM register captures, and debugger logs if required.

Thank you.

Sharif417

Hi Julián,

Thank you for the support.

I followed your procedure with FRET = 1 and added the while(debug) loop before reading DES and FES.

I found that the destructive reset after functional reset escalation works correctly with the while(debug) loop. Without the while(debug) loop, I was not able to observe the destructive reset.

I also confirmed that it works even without using “Attach to Running Target”.

Thank you for helping me to identify this.

Best Regards,
Sharif

View solution in original post

Julián_AragónM

Hello @Sharif417,

1. SWT0 functional reset escalation

SWT0_RSTdoes participate in FREC for S32K312, and when FREC reaches 15, DES[MC_RGM_FRE] is set, which you should be able to read by calling Power_Ip_GetResetReason(), and returning "MCU_MC_RGM_FRE_RESET".

All functional reset sources that are not demoted (through MCRGM.FERD) qualify for incrementing FREC.

Keep in mind that Power_Ip_Init() clears MC_RGM.DES (after saving its value), so try to get the register values before initializing Power module or simply read reset reason.

Recovery Mode may affect this, if the threshold is >8, as Recovery Mode is set to '8' by default. sBAF also may interfere with DRET, not FRET. You can see it is changed to 0xF if it is '0':
Julin_AragnM_0-1788816978772.png

When I run the application continuously, after the 15th functional reset the application/debugger stops instead of allowing me to observe the expected destructive reset. I would like to know whether this is related to the reset sequence, SBAF recovery, or the debugger.
Instead of trying to keep the debugger connected, can you try attaching after a 15th functional reset, or try printing the reset reason through UART or similar?

2. I want every SWT0 functional reset to become destructive

Yes, FRET=1 is enough for every functional reset to issue a destructive reset.
No additional MC_RGM necessary.
sBAF/Recovery Mode should not affect this.
Yes, you can configure it directly in POWER module -> "Module Configuration" -> "McuResetConfig" -> "Functional Reset Escalation Threshold"

3. SRAM data is cleared after every functional reset

Correct, SRAM is preserved after functional reset.
Depending on the derivative, S32K3 may provide 16KB, 32KB or up to 64KB for Standby RAM.
You can find some examples on how to place and use a variable through Standby RAM:

The reason that Standby RAM is being cleared/re-written, is because the default startup_cm7.s provided by S32DS initializes all of SRAM, regardless of reset reason (POR, Destructive, Functional). You must modify it so that if a functional reset is issued, SRAM initialization skips the allocated Standby RAM. Please refer to the following community post: S32K311 standby ram retention.

4. Direct software destructive reset

Yes, when MCU is issued a functional/destructive reset, the debug subsystem and clocks are all re-initialized, meaning the debugger must re-negotiate DAP access again.
A destructive reset leads most parts of the chip, except a few modules, to reset. While a functional reset leads all the communication peripherals and cores to reset. The communication protocols' sanity is not guaranteed and they are assumed to be reinitialized after reset.
Instead of trying to keep the connection, you can use the 'Attach to Target' option for the debugger:

Julin_AragnM_1-1788817136992.png

5. Breakpoint behavior before Power_Ip_PerformReset()

Most likely you are simply missing the window to reconnect. Instead of using a for() loop, you can simply use while(flag), where flag is a variable you will change manually after reconnecting with the debugger, through the 'Expressions' tab.

6. Power IP initialization and Power_Ip_SetMode()

Yes, Power_Ip_Init() must be called before using the Power APIs.
I suggest doing so. You can perform resets through Power_Ip_PerformReset(), however, you can only configure either destructive or functional reset in McuResetConfig container. You can instead declare two power modes: one for functional reset, and one for destructive reset. Then simply call Power_Ip_SetMode(Functional_Reset) or Power_Ip_SetMode(Destructive_Reset).
It can be omitted, however, you should call Power_Ip_SetMode(RUN_MODE) just to make sure every module is correctly gated and configured. If this is not needed in your project, you can omit it.
Please se A6.2.

I've made a simple test, and I can see FRE_RESET reported after setting FRET=1, and performing a functional reset through Power_Ip_SetMode() API:

Julin_AragnM_2-1788817284857.png

Best regards,
Julián

Sharif417

Hello Julián,

Thank you for the clarification.

I have now repeated the tests on my S32K312 and would like to clarify two observations. I am attaching the complete project folder so that you can review the configuration and reproduce the behavior.

1. SWT0 functional reset escalation

I configured:

FRET = 15U;DRET = 0U;

and use SWT0 with a 125 ms timeout to generate functional resets.

I can observe FREC increasing after each functional reset:

SWT0 reset #1  -> FREC = 1
SWT0 reset #2  -> FREC = 2
...
SWT0 reset #14 -> FREC = 14

However, when the next SWT0 functional reset occurs and the FRET = 15 threshold is reached, I am not able to observe the expected destructive-reset status:

DES[MC_RGM_FRE] = 1

Also, after the 15th functional reset, the MCU continues running and I do not observe the expected destructive-reset behavior. The SRAM data stored in my SRAM test partition also remains intact.

I have disabled the recovery behavior using:

IP_DCM_GPR->DCMRWP1 |= (3 << 22);

Could you please review my attached project and clarify:

Why am I not observing DES[MC_RGM_FRE] = 1 after the 15th SWT0 functional reset?
After FREC reaches FRET = 15, should the MCU definitely enter a destructive reset? If a destructive reset occurs, why my SRAM contents is retained in my test partition ?
Is there any additional MC_RGM/SBAF configuration that I am missing?

2. SRAM retention after functional and destructive reset

I created a dedicated SRAM partition/section and stored test data in that region.

I have confirmed that the SRAM value is retained across the repeated SWT0 functional resets, which is expected.

However, even after the 15th functional reset, where I expect FRET escalation to generate a destructive reset, the SRAM value still remains.

I also tested a direct software destructive reset, and the SRAM value was still retained after that reset as well.

My observation is therefore:

SWT0 functional reset
        ↓
SRAM value retained

15th functional reset / expected FRET escalation
        ↓
SRAM value still retained

Direct software destructive reset
        ↓
SRAM value also retained

Could you please clarify whether this SRAM behavior is expected on the S32K312, and whether my SRAM test region may be located in a memory area that is retained even across a destructive reset?

I am attaching the complete S32K312 project folder, including the linker configuration, RTD configuration, MC_RGM configuration, SWT0 configuration, and test application, so you can review the actual memory placement and reset configuration.

Thank you for your support.

Julián_AragónM

Hello @Sharif417,

1. SWT0 functional reset escalation

1. Why am I not observing DES[MC_RGM_FRE] = 1 after the 15th SWT0 functional reset?

As I've mentioned, Power_Ip_Init() API clears DES register, meaning you should read reset reason through Power_Ip_GetResetReason() instead.

2. After FREC reaches FRET = 15, should the MCU definitely enter a destructive reset? If a destructive reset occurs, why my SRAM contents is retained in my test partition?

Yes. As long as FREC reaches the threshold configured in FRET, MCU should issue a destructive reset. Either a destructive reset is not occurring, or variable is wrongly placed.

3. Is there any additional MC_RGM/SBAF configuration that I am missing?

No. For Functional Reset Escalation, simply setting FRET should suffice.

2. SRAM retention after functional and destructive reset

1. Could you please clarify whether this SRAM behavior is expected on the S32K312, and whether my SRAM test region may be located in a memory area that is retained even across a destructive reset?

This should not be the case. All SRAM content is lost after a destructive reset event.

Can you share how exactly are you testing the direct software destructive reset?

From your project, if you are using Power_Ip_PerformReset() API, it is configured as functional reset, not destructive.

Julin_AragnM_0-1788891886849.png

Actually, I tested this by saving the values and share them through UART, where FRDM-A-S32K312, issues a functional reset through SW2, FRET is set to 15, and after 15 SW functional resets, I can see MCU_MC_RGM_FRE_RESET being generated. This is in RTD 6.0.0, please see my log below:

[RESET] Reason : MCU_F_EXR_RESET (RGM_FES F_FR0)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 2
[RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 2
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 3
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 4
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 5
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 6
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 7
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 8
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 9
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 10
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 11
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 12
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 13
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 14
[RESET] Reason : MCU_MC_RGM_FRE_RESET (RGM_DES F_DR6)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1

In RTD 7.0.1, I can see the same behavior you mention (from FRE not asserting destructive reset, to debugger disconnecting):

[RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 2
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 3
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 4
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 5
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 6
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 7
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 8
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 9
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 10
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 11
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 12
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 13
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 14
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 0

This leads me to believe that there are some differences in Power driver between RTD 6.0.0 & RTD 7.0.1 which leads to these symptoms. I have not been able to pinpoint if this is an issue with configuration, or a bug, please give me some time to analyze and contact the internal team if needed.

Best regards,
Julián

Sharif417

Hello Julián,

Thank you for the clarification.

As requested, I have attached the ZIP file containing the software destructive-reset test code/project that I am currently using.

Since you mentioned that the FRET escalation works correctly with RTD 6.0.0, could you please share the working RTD 6.0.0 code/project that you used for your test?

I would like to use your RTD 6.0.0 working code as a reference and compare it with my RTD 7.0.1 project to understand the difference in behavior.

Also, as you mentioned that you suspect there may be a difference or issue in the Power driver between RTD 6.0.0 and RTD 7.0.1, could you please let me know your findings regarding the RTD 7.0.1 issue once you have completed the analysis?

Thank you for your support.

Best regards,
Sharif

Julián_AragónM

Hi @Sharif417,

After going through the source code for Power_Ip driver, I can see a fix for Functional Reset Escalation Counter was applied in Power_Ip_MC_RGM_GetResetReason() API, where a third clause was added, it also enter FES if DES has bits set AND the FRET register currently reads non-zero.

RTD 6.0.0:

/* If the fields of Destructive Event Status Register (DES) are set then the status of FES register must be ignored */
if (((uint32)0U == ActiveValue) || (MCU_POWER_ON_RESET == ResetReason))
{
...
}

RTD 7.0.1:

/* If the fields of Destructive Event Status Register (DES) are set then the status of FES register must be ignored */
/* If functional reset escalation to destructive reset is disabled, then the status of FES register must be ignored if the fields of Destructive Event Status Register (DES) other than DES[F_POR] are set. */
/* If functional reset escalation to destructive reset is enabled and if the fields of Destructive Event Status Register (DES), other than DES[F_POR], are set, then based on these fields user should check if the cause of the destructive reset was due to functional reset escalation or if it was triggered directly by a destructive reset source, in which case FES needs to be ignored */
if (((uint32)0U == ActiveValue) || (MCU_POWER_ON_RESET == ResetReason) || (((uint32)0U != DesResetStatus) && ((uint32)0U != Power_Ip_pxMC_RGM->FRET)))
{
...
}

This is why FES flag is overwritten. If I am correct, destructive reset is issued correctly by hardware, however, Reset module reports a functional reset instead. You can confirm this by reading the IP_MC_RGM->DES register directly after the 15th functional reset:

Julin_AragnM_0-1788976448272.png

I guess a valid approach could be to change the third clause to check if MCU_MC_RGM_FRE_RESET event has already happened:

/* -----------------------------------------------------------------------
 * Enter the FES block if:
 *   a) DES is empty (no destructive reset logged), OR
 *   b) DES has only the Power-On Reset bit, OR
 *   c) DES has bits set  AND  FRE escalation is configured (FRET != 0)
 *      AND the DES reason is NOT already MCU_MC_RGM_FRE_RESET
 * ----------------------------------------------------------------------- */
if (((uint32)0U == ActiveValue) ||
    (MCU_POWER_ON_RESET == ResetReason) ||
    (((uint32)0U != DesResetStatus) &&
     ((uint32)0U != Power_Ip_pxMC_RGM->FRET) &&
     (MCU_MC_RGM_FRE_RESET != ResetReason)))

Keep in mind that modifying the RTD drivers is not supported, and the correct approach is to wait for an official fix from the SW team. I will flag this behavior with the internal team, and provide their feedback, if any. Thank you for pointing this issue out.

Lastly, regarding your project, I can see you are issuing a reset through Power_Ip_PerformReset(). As I've mentioned, you have 'Functional Reset' configured inside the Reset configuration, you must change it to 'Destructive Reset' in order to issue a Software Destructive Reset:

Julin_AragnM_2-1788976691375.png

or add a ModeSettingConf structure, select DEST_RESET, and call Power_Ip_SetMode() instead:

Julin_AragnM_3-1788976695121.png

Best regards,
Julián

Sharif417

Hello Julián,

Based on your recommendation, I performed an additional test by directly reading the MC_RGM DES and FES registers, rather than relying only on Power_Ip_GetResetReason().

In this test, I configured the reset type as software functional reset with FRET = 15. After each software functional reset, the FREC counter increments. After the 15th software functional reset, I placed a breakpoint in main() before Clock_Ip_Init() and directly read the MC_RGM registers:

volatile uint32_t regValueDes = 0U;volatile uint32_t regValueFes = 0U;

regValueDes = IP_MC_RGM->DES;regValueFes = IP_MC_RGM->FES;

gVar = Power_Ip_GetResetReason();

The complete test code is as follows:

int main(void)
{
    volatile uint32_t regValueDes = 0U;
    volatile uint32_t regValueFes = 0U;

    regValueDes = IP_MC_RGM->DES;
    regValueFes = IP_MC_RGM->FES;

    gVar = Power_Ip_GetResetReason();

    Clock_Ip_Init(&Clock_Ip_aClockConfig[0]);

    Siul2_Port_Ip_Init(
        NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals,
        g_pin_mux_000InitConfigArr_PortContainer_0_BOARD_InitPeripherals);

    Power_Ip_Init(&Power_Ip_HwIPsConfigPB);
    gVar = Power_Ip_GetResetReason();

    /* Disable recovery mode */
    IP_DCM_GPR->DCMRWP1 |= (3 << 22);

    for (count = 0; count < 10125000; count++);

    Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB);
}

After the 15th functional reset, I directly read IP_MC_RGM->DES before Clock_Ip_Init(). However, I did not observe DES[MC_RGM_FRE] = 1. The DES value remains 0, while FES contains the reset status (0x20000001 in my test).

Based on this observation, I believe the issue may not be limited to Power_Ip_MC_RGM_GetResetReason() or reset-reason reporting. Since I am directly reading the MC_RGM DES register before the clock and Power initialization, I expected DES[MC_RGM_FRE] to indicate the FRET escalation if the destructive escalation had occurred.

Therefore, could you please confirm whether the FRET escalation itself is occurring at the MC_RGM hardware level after the 15th functional reset? If the destructive escalation is expected at this point, could you please advise why IP_MC_RGM->DES remains 0?

Also, could you please confirm whether there is any additional RTD 7.0.1 issue or configuration related to the FREC/FRET escalation mechanism itself, in addition to the Power_Ip_MC_RGM_GetResetReason() issue you identified?

Thank you for your support in helping us investigate this issue.

Julián_AragónM

Hello @Sharif417,

I believe the destructive reset is indeed happening; you can follow my test procedure below:

Set FRET=1, so each functional reset triggers a Functional Reset Escalation.

Declare two variables (one for DES, and one for FES registers), as well as a while() loop for stopping the core before reading the variables.

int main(void)
{
	volatile uint8_t debug = 1;
	while(debug);
	
	volatile uint32_t regValueDes = 0;
	volatile uint32_t regValueFes = 0;
	regValueDes = IP_MC_RGM -> DES;
	regValueFes = IP_MC_RGM -> FES;
        ...
}

After flashing the MCU with the code, change debug variable to 0 to enable the program to run and disconnect the debugger.
Perform the functional reset (you can use your program, or the example I've provided).
Attach to the MCU by selecting "Attach to Running Target".
Pause the execution, set debug variable to 0, and read DES & FES variables:

Julin_AragnM_0-1789079229563.png

With this method, after generating the functional reset, and attaching, I can see DES[MC_RGM_FRE] bit related to the Functional Reset Escalation procedure.

I'm not sure why you are reading DES->0, if debugger was kept connected, I imagine this meddles with the reset sequence, and generated resets. I suggest testing it with the steps I shared and confirm if DES is really being set or not.

Please keep me informed.

Best regards,
Julián

Sharif417

Hi Julián,

Thank you for the support.

I followed your procedure with FRET = 1 and added the while(debug) loop before reading DES and FES.

I found that the destructive reset after functional reset escalation works correctly with the while(debug) loop. Without the while(debug) loop, I was not able to observe the destructive reset.

I also confirmed that it works even without using “Attach to Running Target”.

Thank you for helping me to identify this.

Best Regards,
Sharif

Julián_AragónM

Hello @Sharif417,

I'm glad you were able to correctly observe this behavior.

I've already reported the Power_Ip_GetResetReason() issue, I am waiting for feedback on this. I can provide more information once the internal team shares it, or you can create a new case or community post to request follow-up information.

Best regards,
Julián

Sharif417

Hi Julián,

Thank you for the update and for reporting the Power_Ip_GetResetReason() issue to the internal team. I will wait for further feedback.

Best regards,
Sharif