Task Stack Peak with configCHECK_FOR_STACK_OVERFLOW set to 2 issue


We have configCHECK_FOR_STACK_OVERFLOW set to 2 on a CortexM devices (some floating point, some not). We have a host tool that reads the stack looking (from the top) for the first non-0xa5a5a5a5 value to determine the stack peak. However we are seeing the peak shrink. For example, the Idle task stack peak is 84 bytes, but then later we see it is 80 bytes.

It looks like the “shrinking” occurs in xPortPendSVHandler when the r4-r11 registers are written onto the stack. The values in those registers are 0xa5a5a5a5 in our case. So they are over-writing previous non-0xa5a5a5a5 values, so it looks like the stack peak is smaller now.

Do you have a recommendation on how to handle this better? I’m reluctant to use configCHECK_FOR_STACK_OVERFLOW = 1 due to backward compatibility.

It seems like pxPortInitialiseStack (e.g. in arm_cm4f/port.c) could be tweaked to not just subtract 8 from pxTopOfStack. Could it also set the R4-R11 values to something other than 0xa5a5a5a5? If this seems like a good solution, could it be incorporated into the next release…possible via a configuration parameter? We’re trying to not modify any FreeRTOS code other than FreeRTOSConfig.h.


Thank for you reaching out. We are looking into how we can support your use case. I will get back to you.