Hello!

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.

Regards,
Anguel

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.

Regards.

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()?

Regards,
Anguel

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.

Regards.

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.