--- 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