FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [January 2013 Threads] Cortex-M3 MPU stack pointer alignmentPosted by Joshua Napoli on 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.
Best, Joshua
RE: Cortex-M3 MPU stack pointer alignmentPosted by Richard on 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.
[Do *not* just delete the "pxTopOfStack--;" line as otherwise the stack pointer will end up pointing outside of the defined stack region when the first task starts]
Thanks and regards.
RE: Cortex-M3 MPU stack pointer alignmentPosted by Richard on 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 )
Regards.
RE: Cortex-M3 MPU stack pointer alignmentPosted by Joshua Napoli on February 5, 2013 Thank you! I'll clear the stack alignment assertion, as you suggest.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|