I have a program running on a Renesas R5F56519ADFP mcu with FreeRTOS
and I encounter a Stack Overflow somewhere in the program when detection method is set to 2.
configCHECK_FOR_STACK_OVERFLOW == 2.
The Heap management Method is Method 3. And malloc and free have been redefined.
As I understand, this method only verifies that the last 16 bytes of the task stack are not overwritten by the task or interrupt activity. When the method is set to 1, the stack overflow is not detected and the Hook function is not executed.
Does this mean that the stack does not really overflows and that only the last 16 bytes can be written by something ?
Is there a method that I can use to determin what writes something in the last 16 bytes of my task stack ?? Because I would like to continue tu use the Method 2 and fix the problem.
Method 1 basically just checks that stack pointer at the time of each context switch to see if the stack is being over run at that time, but can’t detect a transient overrun that is gone by that point (unless you just get ‘lucky’ to get a context switch when it is at that point).
Method 2 writes a pattern into the stack and verifies that last 16 bytes of the stack have that pattern, so if you are using Method 2, you really need to increase your stack by those 16 bytes, and consider that any writing to those IS an ‘overflow’.
Unless your processor has a way to setup a processor trap on an access to those bytes (some debuggers have such an ability), the best way to find it is let the program run just a bit and then hit a breakpoint, see if you have overwritten that part of the stack, if not go a bit farther, if you have, rerun but stop a bit earlier, until you find where the stack is overwritten.
Note, that method 2 can also detect an overflow when there isn’t really an overflow, but instead is a bad pointer use that happens to trash that part of the stack (which is just as bad of a problem, and you are actually lucky if such a problem is detected in this way). You would locate this in a similar manner.
What method 2 does is check that the last 16 bytes still match the fill pattern of the stack. portSTACK_GROWTH = -1 says you stack grows downwards, so the last 16 bytes of the stack are the 16 lowest addresses of the stack memory.
If method 2 is flagging a stack overflow, that says that something has changed one of those last 16 bytes of memory. The most likely cause is that the stack has just grown down into that area (and perhaps past) and you are seeing that overflow. Depending on how well you know your app, it might be possible to look at that memory and recognize a ‘signature’ of some function (if it has some distinctive values on the stack).
One solution is to try increasing the stack allocated to the task that is running out, to see if that fixes it.
As mentioned by Richard-Damon, some debuggers have data breakpoint which allow you to break code execution when the contents of a memory location are changed. If your debugger supports this, you can set a data breakpoint at one of the last 16 bytes of stack.