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).
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 -
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).
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?
@jefftenney
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? 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 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.
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…
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.
