There about a million reasons why your code might not run on the target;
most of which have nothing to do with generating hex code. What makes
you think that it is the hex code generation that is the issue? It seems
the least likely explanation. It is impossible to tell from the limited
information given.

That's fair! Actually, i've been using keil compiler,assembler to
generate hex code from C source for the same hardware which works so
hardware is perfectly fine. Cpu is a Lpc2119/01. Keil uVision3 that i'm
using is actually an evaluation copy and now as the code size has gone
past the limitations, i'm upto gcc and i'm a newbie at that. I guess the
compilation must be ok as,

> arm-elf-gcc -c -O2 -mcpu=arm7tdmi filename.c -o filename.o

this generates the filename.o, but if i just link it now without any
crt0.s  into the filename.elf and then objdump to hex, that isn't
working. How can i go about the crt0.s. How can i make it crt0.o. how
can i use it whil linking. or just please help!! Thnks..

Ok! I have got the thing now and its working on the board so thanks!

alextj wrote:
> This is a really old thread, I'm afraid, but I am in exactly the same
> situation - I have LPC2119/01, code compiled with Keil (uVision demo)
> works,
Using the RV toolset? Or has uVision been used as IDE for a GNU 
toolchain?

> code compiled with GCC-4.2 toolchain from GNUARM doesn't seem to
> work after uploading.
If you have used the RealView tools (uVision default) you have made some 
modifications at least in the startup-code since the RV assembler and 
GNU assembler are not compatible. Please show at least your 
modficiations.

> It's a bit puzzling, since all the information
> about compiling is for Keil, but I can't find anything that would work
> with GNUARM.
There are a few examples for LPC2k and GNU tools freely available. Those 
from my WinARM page might not be the best ones but should give you some 
hints.

> The test code relied on a delay function which
> was optimized out by GCC

It is almost always better to use a hardware timer for delay functions, 
however, you probably used a loop with a non-volatile control variable. 
A good C compiler will see that the control variable is assigned but not 
used, and optimise it out - the whole loop disappears. You must expect 
this to happen regardless of optimisation settings or compiler, and 
simply write the code correctly. If the intent is to create a delay...

volatile int delay ;
for( delay = 0; delay < 100000; delay++ {} ;

The volatile qualifier prevents the compiler optimising out the loop 
under any circumstances on any conforming compiler.

Clifford