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

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

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.

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

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

…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