After i load the image in AXD ,the debug log show ***RDI Warning 00005:
Data abort* immediately, the debugger cannot locate the program counter
at the begainning.
anyone know the why?

I use LPC2212, multi ice and AXD debugger and ADS 1.2
core is ARM7TDMI-S
many thanks Start a New Thread

davidleungcc wrote:
>
> After i load the image in AXD ,the debug log show ***RDI Warning 00005:
> Data abort* immediately, the debugger cannot locate the program counter
> at the begainning.
>

Not sure about the program counter, but, I've found that the JTAG takes
some amount of time to seize control of the processor and stop it.
During that time, the processor can run a lot of code and hit an abort
situation. To avoid that, I put a simple delay loop at the beginning of
the startup code (crt0.S):

========== crt0.S ===========_start:
start:
_mainCRTStartup:

// Initialize Interrupt System
// - Set stack location for each mode
// - Leave in System Mode with Interrupts Disabled
// -----------
;
mov r3, #0x10000
startdelay:
subs r3, r3, #1
bne startdelay // give debugger time to catch us.
;
ldr r0,=_stack
msr CPSR_c,#MODE_UND|I_BIT|F_BIT // Undefined Instruction Mode
mov sp,r0
sub r0,r0,#UND_STACK_SIZE
msr CPSR_c,#MODE_ABT|I_BIT|F_BIT // Abort Mode

========= snip =============
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

Tom.

I simplified the code as below and app_main only have while loop
inside.

The problem still exit.

I have the following concept, pls correct me if i am wrong

1. I generate the intel hex bin and program to the lpc2212 using
philips utility.
2. then i use AXD to load the .elf file
3. the debugger will do matching between the elf file and code
inside ARM while debugging.

Normally the AXD main screen will hold in " ENTRY" point after the
elf file is loaded, but the debug log show "data abort" immediately
now (the main screen show nothing)

the philips data sheet said every time the IC reset,the boot loader
inside(the upper 8k rom in flash)the lpc2212 will run first and
check P0.14 , if it is high, it will make the PC to 0x00000000,is it
related to the problem?

anybody can make a suggestion?

thx for your help
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;
;; startup section
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;
CODE32
AREA startup, CODE, READONLY
ENTRY
;; vector table

LDR PC,=handler_entry_RST;addr_entry_RST
LDR PC,addr_entry_UND
LDR PC,addr_entry_SWI
LDR PC,addr_entry_PAB
LDR PC,addr_entry_DAB
DCD 0xb8a06eb0 ;0x606fa0b8
LDR PC,addr_entry_IRQ
LDR PC,addr_entry_FIQ

addr_entry_RST DCD handler_entry_RST
addr_entry_UND DCD handler_entry_UND
addr_entry_SWI DCD handler_entry_SWI
addr_entry_PAB DCD handler_entry_PAB
addr_entry_DAB DCD handler_entry_DAB
addr_entry_IRQ DCD OS_CPU_IRQ_ISR
addr_entry_FIQ DCD handler_entry_FIQ

handler_entry_UND
b handler_entry_UND

handler_entry_SWI
b handler_entry_SWI

handler_entry_PAB
b handler_entry_PAB

handler_entry_DAB
b handler_entry_DAB

handler_entry_FIQ
b handler_entry_FIQ

handler_entry_IRQ
b handler_entry_IRQ
; LDR PC,[PC,#-0xff0]

;; RESET
handler_entry_RST

;Enable interrupt
;MSR cpsr_c, #0x13 ;;init from app.c OSTaskCreate

;bl init_irq_handlers

mov r3, #0x20000
startdelay
subs r3, r3, #1
bne startdelay ;give debugger time to catch us.

bl init_stacks

;; Main, should never return
;; do not use the name 'main'
;; if the name 'main' used, then ADS will compile the code with
;; the standard C library

ldr lr, =app_main
bx lr

init_stacks
;; cpsr_c = MODE|NOINT;
;; sp = STACK_xxx
mov r0, lr

msr cpsr_c, #MODE_NOINT_UND
ldr sp, =STACK_UND

msr cpsr_c, #MODE_NOINT_ABT
ldr sp, =STACK_ABT

msr cpsr_c, #MODE_NOINT_IRQ
ldr sp, =STACK_IRQ

msr cpsr_c, #MODE_NOINT_FIQ
ldr sp, =STACK_FIQ

msr cpsr_c, #MODE_NOINT_SVC
ldr sp, =STACK_SVC

msr cpsr_c, #MODE_NOINT_SYS
ldr sp, =STACK_SYS

; c_main starts with SYS mode
; SVC mode is not suitable!
; if SVC mode is applied, then SWI cannot be used
; refer ARM developer guide page 5-45 for more details

mov pc, r0

--- In l..., Tom Walsh wrote:
>
> davidleungcc wrote:
> >
> > After i load the image in AXD ,the debug log show ***RDI Warning
00005:
> > Data abort* immediately, the debugger cannot locate the program
counter
> > at the begainning.
> > Not sure about the program counter, but, I've found that the JTAG
takes
> some amount of time to seize control of the processor and stop
it.
> During that time, the processor can run a lot of code and hit an
abort
> situation. To avoid that, I put a simple delay loop at the
beginning of
> the startup code (crt0.S):
>
> ========== crt0.S ===========> _start:
> start:
> _mainCRTStartup:
>
> // Initialize Interrupt System
> // - Set stack location for each mode
> // - Leave in System Mode with Interrupts Disabled
> // -----------
> ;
> mov r3, #0x10000
> startdelay:
> subs r3, r3, #1
> bne startdelay // give debugger time to catch us.
> ;
> ldr r0,=_stack
> msr CPSR_c,#MODE_UND|I_BIT|F_BIT // Undefined
Instruction Mode
> mov sp,r0
> sub r0,r0,#UND_STACK_SIZE
> msr CPSR_c,#MODE_ABT|I_BIT|F_BIT // Abort Mode
>
> ========= snip =============>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net http://cyberiansoftware.com
http://openzipit.org
> "Windows? No thanks, I have work to do..."
> ----------------
> Start a New Thread

I have a confuse between "Load debug Symbols" and "Load image" in AXD
Wht is the difference between them?
thanks for your help

--- In l..., "davidleungcc"
wrote:
>
> Tom.
>
> I simplified the code as below and app_main only have while loop
> inside.
>
> The problem still exit.
>
> I have the following concept, pls correct me if i am wrong
>
> 1. I generate the intel hex bin and program to the lpc2212 using
> philips utility.
> 2. then i use AXD to load the .elf file
> 3. the debugger will do matching between the elf file and code
> inside ARM while debugging.
>
> Normally the AXD main screen will hold in " ENTRY" point after the
> elf file is loaded, but the debug log show "data abort"
immediately
> now (the main screen show nothing)
>
> the philips data sheet said every time the IC reset,the boot
loader
> inside(the upper 8k rom in flash)the lpc2212 will run first and
> check P0.14 , if it is high, it will make the PC to 0x00000000,is
it
> related to the problem?
>
> anybody can make a suggestion?
>
> thx for your help
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
> ;;;;;;;;;;;
> ;; startup section
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
> ;;;;;;;;;;;
> CODE32
> AREA startup, CODE, READONLY
> ENTRY
> ;; vector table
>
> LDR PC,=handler_entry_RST;addr_entry_RST
> LDR PC,addr_entry_UND
> LDR PC,addr_entry_SWI
> LDR PC,addr_entry_PAB
> LDR PC,addr_entry_DAB
> DCD 0xb8a06eb0 ;0x606fa0b8
> LDR PC,addr_entry_IRQ
> LDR PC,addr_entry_FIQ
>
>
> addr_entry_RST DCD handler_entry_RST
> addr_entry_UND DCD handler_entry_UND
> addr_entry_SWI DCD handler_entry_SWI
> addr_entry_PAB DCD handler_entry_PAB
> addr_entry_DAB DCD handler_entry_DAB
> addr_entry_IRQ DCD OS_CPU_IRQ_ISR
> addr_entry_FIQ DCD handler_entry_FIQ
>
>
>
> handler_entry_UND
> b handler_entry_UND
>
> handler_entry_SWI
> b handler_entry_SWI
>
> handler_entry_PAB
> b handler_entry_PAB
>
> handler_entry_DAB
> b handler_entry_DAB
>
> handler_entry_FIQ
> b handler_entry_FIQ
>
> handler_entry_IRQ
> b handler_entry_IRQ
> ; LDR PC,[PC,#-0xff0]
>
>
> ;; RESET
> handler_entry_RST
>
> ;Enable interrupt
> ;MSR cpsr_c, #0x13 ;;init from app.c OSTaskCreate
>
> ;bl init_irq_handlers
>
> mov r3, #0x20000
> startdelay
> subs r3, r3, #1
> bne startdelay ;give debugger time to catch us.
>
>
> bl init_stacks
>
>
> ;; Main, should never return
> ;; do not use the name 'main'
> ;; if the name 'main' used, then ADS will compile the code with
> ;; the standard C library
>
> ldr lr, =app_main
> bx lr
>
> init_stacks
> ;; cpsr_c = MODE|NOINT;
> ;; sp = STACK_xxx
> mov r0, lr
>
> msr cpsr_c, #MODE_NOINT_UND
> ldr sp, =STACK_UND
>
> msr cpsr_c, #MODE_NOINT_ABT
> ldr sp, =STACK_ABT
>
> msr cpsr_c, #MODE_NOINT_IRQ
> ldr sp, =STACK_IRQ
>
> msr cpsr_c, #MODE_NOINT_FIQ
> ldr sp, =STACK_FIQ
>
> msr cpsr_c, #MODE_NOINT_SVC
> ldr sp, =STACK_SVC
>
> msr cpsr_c, #MODE_NOINT_SYS
> ldr sp, =STACK_SYS
>
> ; c_main starts with SYS mode
> ; SVC mode is not suitable!
> ; if SVC mode is applied, then SWI cannot be used
> ; refer ARM developer guide page 5-45 for more details
>
> mov pc, r0
>
> --- In l..., Tom Walsh wrote:
> >
> > davidleungcc wrote:
> > >
> > > After i load the image in AXD ,the debug log show ***RDI
Warning
> 00005:
> > > Data abort* immediately, the debugger cannot locate the
program
> counter
> > > at the begainning.
> > >
> >
> > Not sure about the program counter, but, I've found that the
JTAG
> takes
> > some amount of time to seize control of the processor and stop
> it.
> > During that time, the processor can run a lot of code and hit an
> abort
> > situation. To avoid that, I put a simple delay loop at the
> beginning of
> > the startup code (crt0.S):
> >
> > ========== crt0.S ===========> > _start:
> > start:
> > _mainCRTStartup:
> >
> > // Initialize Interrupt System
> > // - Set stack location for each mode
> > // - Leave in System Mode with Interrupts Disabled
> > // -----------
> > ;
> > mov r3, #0x10000
> > startdelay:
> > subs r3, r3, #1
> > bne startdelay // give debugger time to catch us.
> > ;
> > ldr r0,=_stack
> > msr CPSR_c,#MODE_UND|I_BIT|F_BIT // Undefined
> Instruction Mode
> > mov sp,r0
> > sub r0,r0,#UND_STACK_SIZE
> > msr CPSR_c,#MODE_ABT|I_BIT|F_BIT // Abort Mode
> >
> > ========= snip =============> >
> >
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware.net http://cyberiansoftware.com
> http://openzipit.org
> > "Windows? No thanks, I have work to do..."
> > ----------------
> Start a New Thread

davidleungcc wrote:
>
> Tom.
>
> I simplified the code as below and app_main only have while loop
> inside.
>
> The problem still exit.
>

Did you put the delay loop inside crt0.S (the startup assembly code)???
Again, the JTAG takes *time to catch the processor out of reset*. I
have had the program abort when debugging with the BDI2000 and have lost
control of LPC2106 processors without that delay.

The same holds true for any ARM processor. These things are FAST! The
100..500ms it takes for the JTAG to grab the target CPU gives the CPU
plenty of time to run a LOT of code and slam itself into a wall (abort)!

It doesn't matter how many times you attempt to connect the JTAG to the
processor, it will still abort itself before the JTAG has finished the init.

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

--- In l..., Tom Walsh wrote:
>
> davidleungcc wrote:
> >
> > Tom.
> >
> > I simplified the code as below and app_main only have while loop
> > inside.
> >
> > The problem still exit.
> > Did you put the delay loop inside crt0.S (the startup assembly
code)???
> Again, the JTAG takes *time to catch the processor out of reset*. I
> have had the program abort when debugging with the BDI2000 and have
lost
> control of LPC2106 processors without that delay.
>
> The same holds true for any ARM processor. These things are FAST!
The
> 100..500ms it takes for the JTAG to grab the target CPU gives the CPU
> plenty of time to run a LOT of code and slam itself into a wall (abort)!
>

Tom, I think that this problem primarily occurs in the LPC varient of
ARM processors. In Application Note 31, ARM explains how to start
debugging at the reset vector before ANY code has run. With LPC parts
this is not possible because NXP broke that capability in order to
implement their Code Read Protection scheme. I have worked with ARM
cores that had their nSRST and nTRST implemented correctly, and it is
then possible to start debugging at the RESET vector. I don't know if
all JTAG debuggers can take advantage of the setup in AN31, but I know
for certain that Trace32 does have that ability.
I think that you have him on the right track, but it may be important
for some folks to know that this not a defect of ARM processors in
general? I'm sorry if this divergence was a waste of time.

-- Dave Start a New Thread

derbaier wrote:
>
> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> >
> > davidleungcc wrote:
> > >
> > > Tom.
> > >
> > > I simplified the code as below and app_main only have while loop
> > > inside.
> > >
> > > The problem still exit.
> > >
> >
> > Did you put the delay loop inside crt0.S (the startup assembly
> code)???
> > Again, the JTAG takes *time to catch the processor out of reset*. I
> > have had the program abort when debugging with the BDI2000 and have
> lost
> > control of LPC2106 processors without that delay.
> >
> > The same holds true for any ARM processor. These things are FAST!
> The
> > 100..500ms it takes for the JTAG to grab the target CPU gives the CPU
> > plenty of time to run a LOT of code and slam itself into a wall (abort)!
> > Tom, I think that this problem primarily occurs in the LPC varient of
> ARM processors. In Application Note 31, ARM explains how to start
> debugging at the reset vector before ANY code has run. With LPC parts
> this is not possible because NXP broke that capability in order to
> implement their Code Read Protection scheme. I have worked with ARM
> cores that had their nSRST and nTRST implemented correctly, and it is
> then possible to start debugging at the RESET vector. I don't know if
> all JTAG debuggers can take advantage of the setup in AN31, but I know
> for certain that Trace32 does have that ability.
> I think that you have him on the right track, but it may be important
> for some folks to know that this not a defect of ARM processors in
> general? I'm sorry if this divergence was a waste of time.
>

Interesting. I've been developing on an S3C2410 Samsung ARM processor
and have noticed the same "lag" between when I initiate a JTAG reset and
when it actually "catches" the core. Very much like that the LPC2000
processors.

It's a non-issue with me, for dev work I just put a delay loop in the
startup to give the JTAG time to "catch" the processor.

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

TomW

I got yr meaning, I can run with debugger now with Mulit-ice
derbaier,
I have the problem is that the debugger not start at reset vector

I read through th Application Note 31, it has a method "reset system
on startup" which can start the debugger at reset vector,i tick the
box "resset system on startup" in process setting in AXD, and
connect the nSRST to IC reset pin, but fail when connecting, it
seems the debugger cannot sync with the ARM JTAG after IC reset

Do you success use this method in lpc IC?

thanks for your help.
--- In l..., Tom Walsh wrote:
>
> derbaier wrote:
> >
> > --- In lpc2000@yahoogroups .com 40yahoogroups.com>,
> > Tom Walsh wrote:
> > >
> > > davidleungcc wrote:
> > > >
> > > > Tom.
> > > >
> > > > I simplified the code as below and app_main only have while
loop
> > > > inside.
> > > >
> > > > The problem still exit.
> > > >
> > >
> > > Did you put the delay loop inside crt0.S (the startup assembly
> > code)???
> > > Again, the JTAG takes *time to catch the processor out of
reset*. I
> > > have had the program abort when debugging with the BDI2000 and
have
> > lost
> > > control of LPC2106 processors without that delay.
> > >
> > > The same holds true for any ARM processor. These things are
FAST!
> > The
> > > 100..500ms it takes for the JTAG to grab the target CPU gives
the CPU
> > > plenty of time to run a LOT of code and slam itself into a
wall (abort)!
> > >
> >
> > Tom, I think that this problem primarily occurs in the LPC
varient of
> > ARM processors. In Application Note 31, ARM explains how to start
> > debugging at the reset vector before ANY code has run. With LPC
parts
> > this is not possible because NXP broke that capability in order
to
> > implement their Code Read Protection scheme. I have worked with
ARM
> > cores that had their nSRST and nTRST implemented correctly, and
it is
> > then possible to start debugging at the RESET vector. I don't
know if
> > all JTAG debuggers can take advantage of the setup in AN31, but
I know
> > for certain that Trace32 does have that ability.
> > I think that you have him on the right track, but it may be
important
> > for some folks to know that this not a defect of ARM processors
in
> > general? I'm sorry if this divergence was a waste of time.
> > Interesting. I've been developing on an S3C2410 Samsung ARM
processor
> and have noticed the same "lag" between when I initiate a JTAG
reset and
> when it actually "catches" the core. Very much like that the
LPC2000
> processors.
>
> It's a non-issue with me, for dev work I just put a delay loop in
the
> startup to give the JTAG time to "catch" the processor.
>
> TomW
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net http://cyberiansoftware.com
http://openzipit.org
> "Windows? No thanks, I have work to do..."
> ----------------
> Start a New Thread

--- In l..., "davidleungcc" wrote:
>
> TomW
>
> I got yr meaning, I can run with debugger now with Mulit-ice
> derbaier,
> I have the problem is that the debugger not start at reset vector
>
> I read through th Application Note 31, it has a method "reset system
> on startup" which can start the debugger at reset vector,i tick the
> box "resset system on startup" in process setting in AXD, and
> connect the nSRST to IC reset pin, but fail when connecting, it
> seems the debugger cannot sync with the ARM JTAG after IC reset
>
> Do you success use this method in lpc IC?
>
> thanks for your help.

NO, you can not debug from reset on the LPC parts. The ARM core can be
debugged from reset, as explained in AN31, but the rest of the
hardware implementation must also support it. To debug from reset the
debugger must configure the EmbeddedICE in ARM, and then activate
nSRST without activating nTRST. Part of that configuration, is to set
a hardware breakpoint at the reset vector. If nTRST is activated at
the same time as nSRST the EmbeddedICE will also be reset, deleting
all hardware breakpoints, and the debugger will need to reconfigure
the EmbeddedICE before it can gain control of ARM. On the LPC parts
nSRST and nTRST are internally connected together, so there is no way
that the debugger can be configured to debug an LPC part out of reset.

My only experience with debugging out of reset on ARM was with the
Qualcomm MSM chips containing ARM cores, but they all have nSRST and
nTRST configured correctly. NXP parts have them configured incorrectly
on purpose, so that their Code Read Protection will work. I do not
know about any other chips containing ARM cores.

-- Dave Start a New Thread

I read the Multi-ice data sheet.

Is debug "program run in ROM"(e.g. flash) and "program run in SDRAM"
different?
for debug program in ROM, it need to burn the image to the flash
first and use "Load debug symbol" in AXD, and it works fine.
I try to use "Load image"(instead of "Load debug symbol"), it give
error (data abort) at once.i dont know why, in fact the .axf is the
same.

I am not sure whether "Load image" is used for debug "program run in
SDRAM"
I tested another ARM core which is a philips DECT phone IC, it have
internal flash and RAM, I use "Load image"(instead of "Load debug
symbol), suprisely, it works, the AXD stop at the reset vector
automatically, and press "run", works fine, but before "Load image",
it must burn the image to the flash first.

I wonder what is the reason behind.......

--- In l..., "derbaier" wrote:
>
> --- In l..., "davidleungcc"
wrote:
> >
> > TomW
> >
> > I got yr meaning, I can run with debugger now with Mulit-ice
> >
> >
> > derbaier,
> > I have the problem is that the debugger not start at reset vector
> >
> > I read through th Application Note 31, it has a method "reset
system
> > on startup" which can start the debugger at reset vector,i tick
the
> > box "resset system on startup" in process setting in AXD, and
> > connect the nSRST to IC reset pin, but fail when connecting, it
> > seems the debugger cannot sync with the ARM JTAG after IC reset
> >
> > Do you success use this method in lpc IC?
> >
> >
> >
> > thanks for your help.
> >
> > NO, you can not debug from reset on the LPC parts. The ARM core
can be
> debugged from reset, as explained in AN31, but the rest of the
> hardware implementation must also support it. To debug from reset
the
> debugger must configure the EmbeddedICE in ARM, and then activate
> nSRST without activating nTRST. Part of that configuration, is to
set
> a hardware breakpoint at the reset vector. If nTRST is activated at
> the same time as nSRST the EmbeddedICE will also be reset, deleting
> all hardware breakpoints, and the debugger will need to reconfigure
> the EmbeddedICE before it can gain control of ARM. On the LPC parts
> nSRST and nTRST are internally connected together, so there is no
way
> that the debugger can be configured to debug an LPC part out of
reset.
>
> My only experience with debugging out of reset on ARM was with the
> Qualcomm MSM chips containing ARM cores, but they all have nSRST
and
> nTRST configured correctly. NXP parts have them configured
incorrectly
> on purpose, so that their Code Read Protection will work. I do not
> know about any other chips containing ARM cores.
>
> -- Dave
> Start a New Thread