AnsweredAssumed Answered

FreeRTOS MSP stack corruption

Question asked by Andrew Walsh on Jan 16, 2019
Latest reply on May 6, 2020 by Antony Pace



We are using the IMXRT1052 with the FreeRTOS port provided by the MCUXpresso SDK.


I've recently seen a problem where FreeRTOS looks like it is corrupting the Cortex-M7 Main Stack Pointer (MSP).


We have a main() function which creates an object and some other variables on the MSP (so, an automatic). The object creates a FreeRTOS timer to call one of its methods. The main() function then creates some tasks, and starts the FreeRTOS scheduler. I place a breakpoint in the timer function created by the object, and when it occurs, I find that the object data is corrupted (this is a problem because the timer function makes use of this data!).


Investigating further at this breakpoint, I find that the MSP pointer (the stack on which the object was created) has a *higher* address than it was immediately before the RTOS scheduler was started (e.g. the MSP before RTOS entry is 0x81ffff20, and when the first timer function is entered, it is at 0x81ffffe0), which may well explain why the data is corrupted!

When I dig a little deeper, I find that the FreeRTOS porting function prvPortStartFirstTask() in port.c has an instruction ("msr msp, r0") which explicitly sets the stack pointer back to the MSP address at the start of the application vector table (which is 0x82000000).


Is there any reason why the FreeRTOS port does this to the MSP? This is *not* part of any context switch; this is done with the Process Stack Pointer (PSP), not the MSP.

The items placed on the stack by the main() function should still be there (i.e. the main() function never exits) and so I would say it is not correct for them to be corrupted in this way.


Many thanks,