I am using the ARM7_AT91SAM7X256_Eclipse Demo from V5.0.0 with the minor changes to the following files so it will compile under Linux and run on the Olimex SAM7-EX256:
SrcAtmel/mii.h
webserver/SAM7_EMAC.c
Makefile
main.c
When I compile with cygwin using the latest yagarto (arm-elf-gcc-4.2.2) everything seems to work fine.
When I compile with the gnuarm binary package 4.1 from gnuarm.com (arm-elf-gcc-4.0.2) the Olimex board locks up when I try to ping it, and it has never responded to a ping, when compiling with gnuarm (under ubuntu x86_64 linux)
I also have this problem with gnuarm (arm-elf-gcc-3.4.3) under Linux
Does anybody else have trouble with gnuarm under Linux used w/ FreeRTOS?
It is odd that the same source directories would yield different results like this.
Here is my patch, you can ignore the openocd stuff:
I have not used yagarto to build but have used gnuarm binaries (the prebuilt 3.4.3 and I also compiled 4.1.1) under linux (have not used windows). Both do work, however I have tried compiling working code with the code sourcery compiler and it hasn’t worked, so there must be some differences somewhere.
I believe (could be wrong) the Arm code in the code sourcery compilers gets ported into the main line GCC compiler. I am not to sure what the difference is between mainline GCC and the gnuarm compiler.
I have used both with FreeRTOS, the gnuarm compiler with an STR9 chip and code sourcery with a luminary dev board. Have also used the gnumarm compiler on a STR71x but without FreeRTOS.
I have not really tried to get to the bottom of the problem.
There is a possibility that the compilation may be affected by file letter case ambiguities since it creates a working executable under yagarto in windows (cygwin), but the Linux versions of gcc-3.4.3 and gcc-4.0.2 result in the same defective executable. Maybe this problem only affects the atmel SAM7 MCU’s. I have a hard time understanding though how a case problem would compile successfully, run, but die upon a series of network pings. It usually takes about 5-6 packets to crash the board, though it sometimes takes 1 or as many as 10.
BTW, I am programming both Binaries with the Linux version of openocd and the same scripts and configs. The directory is on a shared mount through a smb share to a windows machine in vmware.