Hi,

please, could someone help me, what I am doing wrong? I have created two tasks, the first is used to generate stack overflow the latter to detect it. In the function vApplicationStackOverflowHook, I am trying to send something (even uninitialized, does not matter) to the queue. The variable pxHigherPriorityTaskWoken is pdTRUE and portYIELD_FROM_ISR() is called. However the vApplicationStackOverflowHook is called again and again. How should I end the vApplicationStackOverflowHook to wake up the function detect_stack_error?

Thank you for your advices.

Regards
Martin

ARM7 - LPC2478 - v7.0.2

xQueueHandle xQueue;
void stack_error( void * pvParameters ) // priority normal
{
       uint32_t stack[40];

for (int i = 0; i < 50; ++i)
{
stack = i;
}

while (1)
{
vTaskDelay(1);
}
}


void detect_stack_error( void * pvParameters ) // priority highest
{
xQueue = xQueueCreate(10, sizeof(unsigned char));
unsigned char a;
while (1)
{
xQueueReceive(xQueue, &a, portMAX_DELAY);
__asm ("NOP\n");
}
}

void vApplicationStackOverflowHook(void *pxTask, char *pcTaskName)
{

(void)pxTask;
portBASE_TYPE pxHigherPriorityTaskWoken;
unsigned char pvItemToQueue;
xQueueSendFromISR( xQueue, & pvItemToQueue, &pxHigherPriorityTaskWoken );

if(pxHigherPriorityTaskWoken)
             portYIELD_FROM_ISR();
}

If you are not running on a system with an MMU, once you have experienced a stack overflow, the system may well be now in an unstable state and not able to continue.

I am also not sure what parts of the API are allowed to be called from the stack overflow routine, and I suspect trying to force a task switch may not be allowed there, as the stack check is happening within the task switch routine.

Normally the overflow hook will be code to somehow output an error message somewhere if possible with primitive code, and then restart the processor.

Generally, unless you are using an MPU port, you cannot recover from a stack overflow. When you have an MPU, you get notification of the stack overflow before any corruption happens as a trap is triggered as soon as a write outside of the region allocated to the stack is attempted. Most ports don't use an MPU, and you only know a stack overflow has happened some time after it has happened - and at that point you don't know what the system state is so all you know is you know nothing. Generally a stack overflow will corrupt a TCB, so the task you are trying to yield from is already corrupt. Even if you are lucky enough that something sensible happens, you will just re-enter the context switch and detect the stack overflow again.

Regards.

Also consider that the stack overflow is called from the context switch mechanism. You cannot attempt to re-enter the context switch by requesting a context switch when you are already in a context switch (if that makes any sense at all ;o).

Hi Richard,

Do you mean to use xQueueSend or xQueueSendFromISR all OK in the stack overflow hook function?

void vApplicationStackOverflowHook(xTaskHandle *pxTask, signed portCHAR *pcTaskName)
{
xQueueSendToBackFromISR(...);
// do not call portYIELD_FROM_ISR();
...
}

or

void vApplicationStackOverflowHook(xTaskHandle *pxTask, signed portCHAR *pcTaskName)
{
xQueueSend(...);
...
}

Yuantu

The context that FreeRTOS calls the vApplicationStackOverflowHook is not suitable for making calls to most of the FreeRTOS API as you are in the middle of the scheduler.

As I said before, at the point where you have detected that you have overflowed the stack, you are really in a state where you can not trust your system, so trying to continue is really not advised.

Thank you very much. That is the reason why pcTaskName can not be printed sometimes when overflow happens just because no stack is available for the task? As you suggested, could things to do in vApplicationStackOverflowHook be flashing LED or loop forever?

Yes. At the point that it has detected the problem, there is significant chance that your system memory is corrupted. Any code there should not depend on the rest of the system being operational. An infinite loop is one reasonable process (possible blinking an led also), or rebooting the system. The reboot can possible pass on the information about why the reboot was caused and the new invocation of the system may be able to send out a message about it, hopefully before the problem reoccurs.