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] [March 2013 Threads] Stack check problem on STM32F4Posted by Dave on March 10, 2013 Hi Folks, I've got a strange problem on an STM32F4Discovery board which is probably sticky fingers, but has got me fooled. This is FreeRTOS 7.4.0. I've created an extremely simple build (summon-arm-toolchain) with no active tasks. I have configUSE_IDLE_HOOK set. When I set configCHECK_FOR_STACK_OVERFLOW to 1, everything is cool, and I can set/trigger a breakpoint in vApplicationIdleHook which implies the code is all cushty. When I set it to 2, I never seem to reach vApplicationIdleHook . I have taken the expansion for taskSECOND_CHECK_FOR_STACK_OVERFLOW from StackMacros.h and pasted it into tasks.c , then replaced the if (memcmp... with a if (1==0)... which results in vApplicationIdleHook getting called again (and no, I'm not running out of stack, I've got breakpoints in there and I've tried setting the stack huge with no change). Hand stepping through memcmp from newlib doesn't reveal anything strange going on either. Its getting late and I will have missed something obvious, but wondered if anyone else had seen any similar behaviour? Regards DAVE
RE: Stack check problem on STM32F4Posted by Dave on March 10, 2013 Spot the newbie who's not used to SF post formatting :-( Hopefully you get the gist from the above despite the rather ridiculous formatting.
Regards
DAVE
RE: Stack check problem on STM32F4Posted by Richard on March 11, 2013 You are the second person to have this problem - both times it has been with the summon ARM tools. If you can get down to the bottom of the following post you will see that last time it appeared to be some peculiarity with the libraries (or lack of libraries) provided with the tools:
http://www.freertos.org/FreeRTOS_Support_Forum_Archive/February_2013/freertos_FreeRTOS_stack_corruption_on_STM32F4_with_gcc_6772412.html
Regards.
RE: Stack check problem on STM32F4Posted by Dave on March 11, 2013 Richard,
Thanks for the quick reply.
Hmm...I was getting to the point of blaming the environment, but that's usually an easy get-out when your own code doesn't work. OK, will investigate further this evening. I have to find out what's going on, otherwise I'll feel like I'm building on sand. Happy to snapshot this build/tools and send it to you if it's useful....there's nothing in it anyway.
DAVE
RE: Stack check problem on STM32F4Posted by Dave on March 11, 2013 OK, had a quick dig and changed over from the summon (Linaro) toolchain to gcc-arm....used the pre-compiled version to make sure I've got something the same as others. Linking with newlib from there resulted in the same behavior but linking with the nano lib (--specs nano.specs) results in a correctly working system.
My guess is that something in the way newlib is built results in some strange alignments and without the same incantations for the app there's an incompatibility that shows up as the RTOS not scheduling tasks. I don't really want to be using newlib anyway so for now the solution for me is to move to the nano library. I'll have a quick peek at the build script for the gcc-arm to see if there's anything obvious in there - if I see anything I'll post back for others. In the meantime Richard you might want to note that there may be some issues using newlib (at least without specific incantations on the compile and link lines).
Regards
DAVE
RE: Stack check problem on STM32F4Posted by Dave on March 11, 2013 ...just can't avoid picking at the scab.
The problem was I was missing the -nostartfiles option from the linker step. Add that in and everything works fine with both newlib and nano.
So, sticky fingers wins.
Regards
DAVE
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|