I've been trying to build the subject demo program (FreeRTOS V4.2) using the current YAGARTO gnu-arm toolchain under Windows XP Pro. Until today I've not modified any source files or the makefile. The resulting binary image file is programmed into an AT91SAM7X256 on a AT91SAM7X-EK board. The demo program built using the supplied makefile and unmodified source files does not run correctly. The LEDs flash as expected, however the first http request causes the system to crash. I have Ethereal packet captures that document the errant behavior. Ping (ICMP) requests to the SAM7X do not cause a problem, however the very first web page request kills the system.

Modifying the makefile to change the compiler OPTIM setting from OPTIM=-O0 to OPTIM=-O3 then rebuilding the rtosdemo.bin file results in a working demo program.

I am using arm-elf-gcc version 4.1.1. Other optimization levels may also work, but I've not yet tried others.

While it's good to see the FreeRTOS software run as expected, I am hoping to track down the reason why the unoptimized code causes a problem. Generally execution problems are more common with OPTIMIZED code. I am concerned that source level debugging using gdb may not be possible with this optimization level.

Anyway, I wanted to share this information with other uses. I've spend quite a bit of time tracking down the nature of the problem and other might also.

Dave Squires
SQUIRES ENGINEERING, INC.

Seems you have come across a problem that was discussed a little while back. Search the forum for "-fomit-frame-pointer". Somebody (sorry forgot who) discovered a bug in GCC whereby the task epilogue code (if I remember correctly) cleans up the stack in a way that is not interrupt safe. Using the -fomit-frame-pointer or setting optimisation to 1 fixes the problem.

Hey, that's very good information - thanks. I only recently joined the forum and did check recent posts for a similar problem first before my post.

Perhaps the makefile should be updated in the FreeRTOS distribution. I've also posted to FreeRTOS forum so they'll likely be telling me the same thing.

Thanks,

Dave Squires

It has been updated in the latest download, even the last couple of downloads I think judging by the change history.

I appreciate the quick responses from all. I've modified my makefile to use the -fomit-frame-pointer option and all is now well with the build. I've already gotten a new task going and sending UDP packets periodically.

Thanks again,

Dave Squires

Hello there,

I am trying with the lwIP_Demo_Rowley_ARM7.
I use ATMEL SAM-ICE.

The demo build ok but when I run Start Debugging it shows:
"Write momory error @ address 0xFFFFFD00, word access timeout.
can not read register, cpu may not be halted....."

can any one help?

Thanks!

Sounds like it could just be a debugger setup problem. Are you using the Rowley IDE, or command line GCC?

I'm not familiar with the SAM-ICE.

Regards.

Seems like there is cross thread problem in this post but to the question about the IwIP_Demo_Roley_ARM. I had the same problem. I took the AT91SAM7_Target.js file from the CrossStudio install directory C:\Program Files\Rowley Associates Limited\CrossWorks for ARM 1.6\targets\Atmel_AT91SAM7\ and replaced the on in the ..\FreeRTOSV4.2.1\FreeRTOS\Demo\lwIP_Demo_Rowley_ARM7\ dirctory and it fixed the problem. I have not take time to find out why...

Bill