prvTaskExitError() present at start of call stack.

illysky wrote on Monday, July 03, 2017:

Hi All

I am running FreeRTOS v8 and lwIP on STM32F417 - based on STM32F4 cube example.

I have a couple of tasks running including HTTP client and DHCP client. All runs fine for about 24 hours then I get a hard fault.

When restarting and halting in each task (uVision), I noticed at the start of the call stack I was seeing prvTaskExitError. Which is confusing as I thought that only get called when you attempt to leave a task and to that point my tasks are exiting anyway. Sometimes there were even x2 prvTaskExitError in the call stack.

Through trial and error, I changed all my tasks variables to static and I never saw prvTaskExitError in the call stack again, and no more hard faults.

Alot of googling, and I can seem to find anything…Is that normal? I obviously want to make sure I am doing this correctly.

Best Regards


jalegre2003 wrote on Monday, July 03, 2017:

As far as I know, the first function in the call stack should always be prvTaskExitError.
If the function executing immediately below (the task code) at the call stack exits, the code will get again at prvTaskExitError, effectively trapping the error.

richarddamon wrote on Monday, July 03, 2017:

SOME ports setup the prvTasskExitError return, but not others.

I think what happens if you simplify that stack frame enough for your task, is that the compiler might change its stack usage to not setup a stack frame, which may confuse the debugger and not give you the traceback.

The prvTaskExitError address on the stack is totally not a problem, as you shouldn’t be returning there anyyway.

illysky wrote on Monday, July 03, 2017:

Thank you for your speedy responses, very grateful. That’s good to know about the prvTaskExitError.

In relation to the hard faults, when I set up a “simple” task (static variables) - I never see the hard fault, but when I leave them as local (auto) variables in the task, I get an intermittent hard fault (12hrs ish in to runtime) with unaligned memory access fault (always in the tcpip thread of lwip).

Do you have any suggestions to what I could be doing wrong…have you seen this behaviour before? or is it indicitive of something? I appreciate that hard faults are tricky to diagnose - ive exhausted my debug skills!!

many thanks again


rtel wrote on Monday, July 03, 2017:

I was going to suggest it might be a stack overflow problem, but it
looks like you know it is a misaligned access issue within lwIP. All
the same, its best to ensure you have stack overflow checking turned on.