Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Question about vApplicationStackOverflowHook

Posted by on June 14, 2011

When I look at this function:
void vApplicationStackOverflowHook( xTaskHandle *pxTask, signed portCHAR *pcTaskName );

I get the impression that one is able to receive the handle to and the name of the overflowing task through pxTask and pcTaskName. Is this correct? On the other hand I am a bit confused, because the function does not seem to return a pointer to an xTaskHandle but just an xTaskHandle as pxTask.


RE: Question about vApplicationStackOverflowHook

Posted by Richard on June 15, 2011
Nothing is returned, only input into the function.

Yes you are correct that the task name and handle are passed in to assist in identifying the offending task. However, note that often a stack overflow will result in these values being corrupt anyway - in which case you have to inspect the pxCurrentTCB variable directly.

Recovering from a stack overflow without restarting/resetting is extremely difficult unless you are using a microcontroller and FreeRTOS port that support an MPU. That is because, without an MPU you only know the corruption has occurred after it has occurred so don't necessarily know what is corrupt (unless you allocate a lot of padding after the stack), whereas with an MPU you know a corruption is about to happen before it actually occurs so get a chance to prevent it.


RE: Question about vApplicationStackOverflowHook

Posted by on June 15, 2011
Thanks for the detailed explanation!

Actually I had tested the following on PIC32 before asking:

void vApplicationStackOverflowHook(xTaskHandle *pxTask, signed char *pcTaskName )
bad_task_handle = pxTask; // this seems to give me the crashed task handle
bad_task_name = pcTaskName; // this seems to give me a pointer to the name of the crashed task
mLED_3_On(); // a LED is lit when the task has crashed

for( ;; );

As you say, both bad_* variables may contain unreliable information because of the overflow. BTW the FreeRTOS book says that only the task name may be corrupt for some reason.

Is it a good idea to at least "try" to perform a MCU reset from the vApplicationStackOverflowHook()?


RE: Question about vApplicationStackOverflowHook

Posted by Richard on June 15, 2011
If your application can cope with a reset, then that is a reasonable thing to do. However, I would say, what you don't want is your system continuously or sporadically resetting without you knowing - just because a stack somewhere needs a little adjustment - so if the hook function is called you want it logged somewhere.

Another point is, the hook function is called from the tick hook. That means, in the code you posted above, while you sit in the null loop no tasks will execute. However, interrupts that have a priority above the tick interrupt will continue to execute. If you want to halt everything then globally disable interrupts before entering the null loop.


RE: Question about vApplicationStackOverflowHook

Posted by on June 15, 2011
You are right, during development a MCU reset in the hook is pointless. I thought of using the reset in a production system, just in case some overflow occurs for some reason.

Also thanks to the hint with the interrupts.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner