Cortex-M3 MPU stack pointer alignment

joshuanapoli wrote on Tuesday, January 29, 2013:

In FreeRTOS-7.3.0, xTaskCreateRestricted gives an assertion failure when checking stack pointer alignment after pxPortInitialiseStack:

ASSERTION FAILED at vendor\FreeRTOS\FreeRTOS\tasks.c:560: ( ( ( unsigned long ) pxNewTCB->pxTopOfStack & ( unsigned long ) ( 0x0007 ) ) == 0UL )

I checked that the stack base and length passed in are both well-aligned. I’m doubtful about the first line of pxPortInitializeStack, “pxTopOfStack-”. The initial decrement skips the topmost word of the stack and results in an odd number of words being pushed.


rtel wrote on Wednesday, January 30, 2013:

xTaskCreateRestricted() calls xTaskGenericCreate(), which is the only function that actually creates tasks (but is never called directly as it is not part of the public API).

The assert in question passes with the Cortex-M3 port, but a quick look at the code shows why it fails with the Cortex-M3 MPU code.  The MPU version has one more item on the context stack, meaning the end stack alignment is different to that with the non MPU version (the assert was added after the development of the MPU port).

The MPU version therefore ends up with 4 byte alignment, instead of the required 8.  In the vast majority of cases this is not going to effect your code.  The only time it has ever been known to cause a problem on Cortex-M ports is when printf()'ing a floating point number, as in “printf( “%f”, a_float_variable)” - in which case 0.0 was always printed out instead of the real value.  It is conceivable, although I have never tested it, that using 64-bit numbers with compiler optimisation might also result in incorrect value.

At the top of FreeRTOS/Source/portable/GCC/ARM_CM3_MPU/port.c you will find the function pxPortInitialiseStack(), as referenced in your email.  At the top of that function you will see the line pxTopOfStack-;  Please change that to instead read “pxTopOfStack -= 2;” and let me know if everything is still ok, and the assertion passes.

Thanks and regards.

rtel wrote on Thursday, January 31, 2013:

I’ve just tested this now and the stack alignment in the release code is *correct* and the additional line should not be added to port.c.

Instead, the following can be added to portmacro.h (I have done it in the main line code now) to allow you to use the configASSERT() macro.

/* There are an uneven number of items on the initial stack, so 
portALIGNMENT_ASSERT_pxCurrentTCB() will trigger false positive asserts. */
#define portALIGNMENT_ASSERT_pxCurrentTCB ( void )


joshuanapoli wrote on Tuesday, February 05, 2013:

Thank you! I’ll clear the stack alignment assertion, as you suggest.