S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention 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. Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention 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.pngJulin_AragnM_0-1788816978772.pngJulin_AragnM_0-1788816978772.pngJulin_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:
[RTD600 MCAL & IP] S32K3 Low Power Management AN and demos
S32K3 Low Power Management AN and demos
Example S32K312 Standby mode & Standby RAM and PAD keeping DS3.5 RTD300
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.pngJulin_AragnM_1-1788817136992.pngJulin_AragnM_1-1788817136992.pngJulin_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.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.pngJulin_AragnM_2-1788817284857.png
Best regards, Julián Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention 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. Re: S32K312: SWT0 Functional Reset Escalation, Destructive Reset Status and SRAM Retention 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.pngJulin_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
View full article
