S32K314 FreeRTOS Standby Transition and Return to Run Mode I am developing a project that combines interrupts and tasks using the S32K314, RDT 7.0.0, and FreeRTOS 7.0.0. The interrupts and tasks are functioning properly. I have implemented code that transitions from Run mode to Standby mode and returns to Run mode after a specified time has elapsed as measured by the RTC. I have confirmed that the system transitions from Run mode to Standby mode, and that a reset occurs afterward, causing the MCU bootloader to run again. However, an error occurs during the process of distributing the clock to the MCU peripherals after the MCU initialization begins and the PLL locks. Since it works during P.O.R., I believe there is some error in the process that transitions the system to Standby mode. Could you please help me? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Additional Information: This project defines Standby RAM. The RAM is allocated as a 32-kilobyte region starting from the beginning of the BSS. This region stores the necessary data after resuming from Standby. /*--- Transition to Standby Mode ---*/ /* Set the timeout for the RTC timer to wake up WKPU0 */ Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds); /* Suspend all OS tasks */ vTaskSuspendAll(); /* Initialize the clock mode to Standby */ Mcu_InitClock(McuClockSettingConfig_Standby); /* Set the clock mode */ Mcu_SetMode(McuModeSettingConf_Standby); ..... (Reset Occur) /*--- MCU Initialization ---*/ /* Set the Standby RAM area to non-cacheable */ MpuConfigurator_AllocateStandbyRamToNonCacheable(); /* Enable non-cacheable mode */ MpuConfigurator_Enable(); /* Initialize the MCU module */ Mcu_Init(NULL_PTR); /* Initialize clock settings in Run mode */ if (E_OK == Mcu_InitClock(McuClockSettingConfig_Run)) { /* Wait for PLL lock via polling */ while (MCU_PLL_LOCKED != Mcu_GetPllStatus()) { /* Wait until the PLL locks */ } /* Distribute the PLL clock to the system */ Mcu_DistributePllClock(); ← An error occurs here Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi @Teruhiko,
Could you find more information about the error? What type of fault exception is it?
https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259
https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570
https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447
You could also step through the code to identify the exact location where the exception is triggered.
Check the DCM_GPR registers for any error. RM, Table 231. DCM controlled features and availability in product family.
It could be because of incorrect SRAM initialization after the reset.
There is ERM that monitors that, but the clock of the module is gated of by default.
Thank you,
BR, Daniel Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi danielmartynek-san, I apologize for the delayed response. Since communication with J-TAG is lost when the system transitions to Standby mode, I have not yet been able to obtain the detailed error information. I am currently writing debugging code. I would like to share what we currently know. I have investigated the reset causes under the following conditions: ・ Automatic reset recovery after an RTC timeout following a transition to Standby mode → Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt while in Standby mode after entering Standby → Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt after the RTC times out following a transition to Standby mode → Reset cause: MCU_POWER_ON_RESET I believe the reset factor is correct. I suspect that the differences in the boot sequence for each reset factor are related. Once I have more details about the error, I will respond separately. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko,
After the MCU exits Standby mode, it should be possible to attach the debugger. For easier debugging, consider adding an infinite loop at the start of the application so you can connect the debugger and step through the execution from there.
volatile int var = 1;
while(var){}
If MCU_POWER_ON_RESET is observed instead of MCU_WAKEUP_REASON, please check the following registers: DCMROPP1–4.
Thank you,
BR, Daniel
Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko,
The clocks looks good.
One question: when you run the MCU standalone after a POR (without the debugger), does the application work? The reason I’m asking is that when the application is started via the debugger, the debugger performs part of the system initialization. In standalone operation, the application must handle this initialization itself. After exiting standby, the MCU goes through a reset and the debugger is disconnected, so the behavior is effectively the same as a standalone startup. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, I apologize for the delayed response. I had some questions regarding our circuit design, so I was investigating how it related to this issue. As a result, I discovered that there was a problem with the port assignments in the circuit. When a reset occurred upon waking from standby, the supply voltage applied to the MCU became unstable. I greatly appreciate all the support you’ve provided so far. Thank you very much. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko,
What is the Mcu_InitClock(Standby) configuration?
It still should be one of the Clock options e.g. Table 157. Option A - High Performance mode (CORE_CLK @ 160 MHz).
What exactly do you mean when you say it behaves erratically or is unstable?
Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi daniel-san Thank you for your advice. I was able to reattach after resetting. When I step through the code, the MCU peripheral initialization succeeds, but the program behaves erratically when I call “xSemaphoreCreateRecursiveMutex()” during the process of starting the OS task. Furthermore, when stepping through this function, the behavior becomes unstable at the following section of the function `void * pvPortMalloc( size_t xWantedSize )` in `heap_4.c`. It appears that heap allocation is failing. Are there any steps I should take before transitioning to Standby mode? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, The settings for “Run” and “Standby” modes in this project are shown below. I believe the settings in Table 157 that you provided have been applied to Run mode. I also believe the clock values in Table 160 have been applied to Standby mode. I am setting a clock to these blocks so that the RTC can measure time and the WKPU can trigger a reboot. As I step through the code, the current information is displayed on the IDE console screen. When you execute the aforementioned “heapVALIDATE_BLOCK_POINTER()”, the console screen begins to scroll, and step execution becomes impossible . Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Here’s how to transition to Standby mode. ・In the MCAL MCU module settings, “STANDBY” has already been selected as the Operation Mode for Standby mode. ・In the Clocks tool of Design Studio, I have already created separate Functional Groups for “Run” and “Standby.” 1. In normal operating mode, call the functions in the order “Mcu_InitClock(Run)” and “Mcu_SetMode(Run)” to operate in Run mode. ... 2. To transition to Standby mode, call “Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds)” to start the timer, which will automatically wake the system up in Run mode after a specified time via the RTC. 3. Call “vTaskSuspendAll()” to suspend all running OS tasks. 4. Call “Mcu_InitClock(Standby)” followed by “Mcu_SetMode(Standby)” to transition to Standby mode. The reason for calling vTaskSuspendAll() is based on the information in the link below. https://community.nxp.com/t5/S32K/S32K312-Does-FreeRTOS-need-to-be-shut-down-before-entering/m-p/1756857
查看全文
