FreeRTOS under GCC with -O0 option

has anybody compiled for arm7tdmi with -O0 option using gcc 4.1.1? My OS under at91sam7s256 still crashes without optimalization :( Janusz

FreeRTOS under GCC with -O0 option

interesting links for trace/debug: http://www.embedded.com/showArticle.jhtml?articleID=192202641 http://www.l8night.co.uk/mwynn/gbadev/asmdocs/gba-arm-asm.html Janusz

FreeRTOS under GCC with -O0 option

The makefiles for the LPC2000, AT91FR40008 and AT91SAM7X256 ARM7/GCC projects in the download use -O0, so it must be possible. Using -O0 will make the code and stack useage greater.  Is this the problem rather than the code gen?

FreeRTOS under GCC with -O0 option

I added the -fomit-frame-pointer option so the frame was not used when calling a function (indeed is not needed) and I can change the optim level without worrying. Can you test it? Thanks

FreeRTOS under GCC with -O0 option

You are my master!!! I have added and OS work with everthing with -O0 flag!!! Thanks a lot!!! Janusz

FreeRTOS under GCC with -O0 option

with -O0 works fine with -O1 crashes (but it is no this reason -> then gcc uses a lot of stack) with -O2 works fine best regards Janusz

FreeRTOS under GCC with -O0 option

I was wrong, with -O2 can crash also bu -O0 is great:) thanks again Janusz

FreeRTOS under GCC with -O0 option

reason: -O2 causes more stack usage! Janusz

FreeRTOS under GCC with -O0 option

I was having issues with FreeRTOS 4.1.0, GNUARM 4.11 and the LWIP SAM7 demo package until the -fomit-frame-pointer was put into the makefile.  The AT91SAM7X256 is running now.

FreeRTOS under GCC with -O0 option

I experienced the same problem with dsPic. Does anybody know why Frame Pointer crashes with FreeRTOS? Is it because somehow both are pushing and popping the stack? Cheers. Dennis

FreeRTOS under GCC with -O0 option

Don’t suppose you’ve tried the webserver side of it have you?… cos it’s not working here.

FreeRTOS under GCC with -O0 option

Scratch that, my switch locked up. Sorry :)

FreeRTOS under GCC with -O0 option

I think there is a bug in ARM7 GCC that holds the pointer in an invalid place for a few cycles.  Search the forum for "-fomit-frame-pointer" and there is an explanation.  It may even be in this thread.