Application stack overflow help on static task


We are having difficulty pinpointing why a statically created task is causing the overflow hook to fire. This is the offending task in the callback:

FreeRTOS version is 10.5.1.

The stack size is set to #define RECV_STACK_SIZE (4096 / sizeof(StackType_t)). configCHECK_FOR_STACK_OVERFLOW. To that point, a hardware watchpoint at the end of the stack never fires, which is what we’d expect according to the documentation.

Any pointer on where we should look next?

This appears to happen as soon as the scheduler starts to run. We have other static tasks created in the same exact fashion, and they work fine. If the task is modified so it does nothing more than just a while (true) { vTaskDelay(…) }, the same issue occurs.


A watch point on a particular location of memory might not fire if it happens to be on a variable location that doesn’t actually get written to. You should be able to look at the stack memory and see at what point in the code you are currently running at, to see what is happening.

You could also just make the stack size bigger, or move the probe around a bit to see if you can find a location that is written to. (look at the stack memory and see where the fill bytes have been overwritten).

Thanks, Richard. Does this seem suspect to you?

It’s not the overflow check firing the fault?

The task selection is actually causing the corruption?

Don’t worry too much about taskSELECT_HIGHEST_PRIORITY_TASK() being highlighted in the debugger when you select vTaskSwitchContext() in the call stack. That highlighted line is next up for execution after taskCHECK_FOR_STACK_OVERFLOW(). And your stack overflow hook was running when the debugger halted.

A couple of questions for you -

  1. Is your data breakpoint on the correct end of your stack? I’m assuming your stack grows downward in memory. In that case your data breakpoint is at the wrong end. FreeRTOS stack limit checking validates only the 4 words at the maximum height of the stack (lowest addresses).
  2. What MCU are using using? CC1354P10? That is a Cortex M33 which has stack-limit registers so you should not need configCHECK_FOR_STACK_OVERFLOW at all. Which FreeRTOS port are you using?

Thanks, Jeff. Correct that this is a CC1354P10.

I was watchpointing in the areas of what pxEndOfStack was pointing to.

So, interesting, I set the configCHECK_FOR_STACK_OVERFLOW to 0 and things are up-and-running after a quick sanity boot.

So what have we actually proven here? :slight_smile: Is setting the overflow check to “0” correct for this architecture? Just curious if there is some kind of documentation you can refer me to.

Nothing yet :slight_smile: It does appear that configCHECK_FOR_STACK_OVERFLOW lucked into finding a memory corruption, but probably not a legitimate stack overflow (assuming you are using the M33 port). Had it been a legitimate stack overflow, the stack-limit registers would have triggered their associated usage fault.

On to the issue of where to put your data breakpoint. Instead of near pxEndOfStack, put it near pxStack. Maybe on pxStack[0] or pxStack[1]. Those are the memory locations that configCHECK_FOR_STACK_OVERFLOW uses and checks. Again that’s because the stack grows downward, to lower memory addresses. Hopefully that will help you find the code that is errantly writing to those addresses.


Still no luck on those locations. Here is just after initializing the stack and setting the ucStaticallyAllocated flag:

Here’s the same memory location after the fault:

But what’s interesting is, there are two other stacks created using xTaskCreateStatic(). They both start with 0xA5A5A5A5, whereas this particular crashed stack buffer starts with 0x00000200.

So it seems like part of the TCB is being written into the stack buffer during init?

I believe the issue has been isolated: Since this appears be an alignment problem, we found a packed struct of size 13. Removing the packing and quad-aligning shows that the tasks are up and running and their TCBs are stacks are healthy…

Thanks for taking the time to report back.