Other reasons for hitting prvTaskExitError()

eyalasko1 wrote on Wednesday, October 17, 2018:


I’m running a pretty extensive app with 5 tasks (1xpriority 1, 3xpriority 2, 1x priority 3).
Occasionally, I fall into assert handler in prvTaskExitError() .

What can be a possible reason for this (other than returning from task’s function in code which is not the case).

Some thoughts-

Can task stack overflow be the cause? I’ve turned on the stack tracking flag and hook function as advised but the software doesn’t end there (only in prvTaskExitError()) .
Can it be an overflow that is undetected (happens before context switches)?

Is there a (syntactical) way in C that enable inner functions trigger a return of the calling function?

How can a task’s TCB be altered so that the task returns?

Any other idea will be highly appreciated.

rtel wrote on Thursday, October 18, 2018:

In theory, if everything is executing normally, the only way to end up
there would be for a task to return from its implementing function (as
you said). Anything else would indicate some kind of corruption.
Either, the program counter has jumped somewhere it should not have done
and is just executing random stuff until it hits an infinite loop (like
the assert in the exit error function), or something has gone wrong with
the stack and an entire stack frame is skipped so the return address for
a function instead returns to the exit error function. The first case
is much more likely than the second. Even if a library function
unbeknown to you called exit() you would not end up in the exit function.

Have a look at the map file for the application to see where the task
exit error function is in memory - if it is preceeded by empty space
then it might be the empty space is executed as a whole load of NOP
instructions that the processor will run through until it happens by
chance to hit the exit function.

eyalasko1 wrote on Wednesday, October 24, 2018:


Eventually (after few sleepless nights :wink: it was found to be an ‘out of bounds’ access to an array which led to the hardfault.

Warm recommendation - spare yourself time and agony and use ASSERT() wherever possible to verify your data is valid.
I did it in 1000 places but not in that specific function :frowning:

Thanks again for your prompt reply.