Lpc2000

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
> Reading your post, one assumes that the processor is being caught right 
> at startup by the JTAG debugger.  However, this reminds me of a problem 
> I ran into very early in development.  I had a bad situation where the 
> program would ABORT, I tried to use the JTAG to find the problem but
the 
> JTAG would only connect me to an aborted processor.
> 
> The problem was this, the JTAG (BDI2000) would reset the CPU, then
delay 
> for a short interval and then go through the process of stopping the
CPU 
> via the JTAG chain.  During the time between the reset inactive and
when 
> the JTAG finally "caught" the processor, the CPU had run through a
large 
> number of instructions and hit the abort point.
> 
> This was solved by placing a delay loop in the crt0.S file

I did try adding the delay loop before the branch to _start, but it
didn't seem to make a difference.  When I first started debugging I
simply set a breakpoint a ways into my main() routine.  It hung.  I
did a break and found it stuck in the undefined instruction routine
(which just branches to self).  I then set a breakpoint at the branch
to _start and started stepping from there to see what it didn't like.
 JTAG is indeed the debugger connection, but the program was free
running when I first tried it, so I'm thinking JTAG shouldn't be
creating a problem.

Note that I am using the binary version of the GNU tools.  I did not
download source for 4.0.2 (and indeed source code was NOT shipped with
the Keil debugger either, just the binary version).  My startup file
ends with a branch to _start which is supplied by the GNU library so I
don't have control over what it is actually calling.  Interestingly
enough, when I used the older version of GNU I was fine until I added
a call to sprintf which of course brought in more library functions. 
It took awhile to crash, but did eventually.  Using 4.0.2 it seems to
be unhappy with or without sprintf.  I disassembled the code it jumps
to for _start, which looks like so:

0x00000258  E3A00016  MOV       R0,#0x00000016
0x0000025C  E28F10E8  ADD       R1,PC,#0x000000E8
0x00000260  EF123456  SWI       0x00123456
0x00000264  E59F00E0  LDR       R0,[PC,#0x00E0]
0x00000268  E590D008  LDR       R13,[R0,#0x0008]
0x0000026C  E590A00C  LDR       R10,[R0,#0x000C]
0x00000270  E28AAC01  ADD       R10,R10,#0x00000100

It is the SWI that it doesn't like.    Does the code snippet seem
right?  Is there a problem with the precompiled libraries?

One last bit of info, if it helps, the compile and link options
created by Keil are:

-c -mcpu=arm7tdmi -mthumb -gdwarf-2 -MD -Wall -O -mapcs-frame
-mthumb-interwork -IC:\Keil\ARM\INC\Philips\ -o *.o

and

-T .\LinkerScript.ld -mthumb-interwork -Wl,-Map=".\lst\bs1200.map" 
,-Ttext=0

Rebekah