--- In l..., Tom Walsh wrote:
>
> derbaier wrote:
> >
> > pre-programmed with an algorithm applicable to the FLASH being used,
> > and then you just need to get the symbol table into the debugger.
> >
> > >
> > > I am not sure whether "Load image" is used for debug "program run in
> > > SDRAM"
> >
> > You can use "Load image" on any writable memory.
> > >
> > >
> > Heh, that might be the problem, he might not be loading the program
into
> RAM but into an area which has nothing in it, no RAM, no Flash,
> nothing. That would cause the CPU to throw an abort. I've aborted
when
> loading via JTAG.
>
> TomW
>
So have I.
I have also got those kind of aborts by doing a memory dump and
accidently getting the dump range outside of useable memory.

-- Dave Start a New Thread

derbaier wrote:
>
> pre-programmed with an algorithm applicable to the FLASH being used,
> and then you just need to get the symbol table into the debugger.
>
> >
> > I am not sure whether "Load image" is used for debug "program run in
> > SDRAM"
>
> You can use "Load image" on any writable memory.
> >
>
Heh, that might be the problem, he might not be loading the program into
RAM but into an area which has nothing in it, no RAM, no Flash,
nothing. That would cause the CPU to throw an abort. I've aborted when
loading via JTAG.

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:
> I read the Multi-ice data sheet.
>
> Is debug "program run in ROM"(e.g. flash) and "program run in SDRAM"
> different?
>
Yes, because the debugger can load RAM, but FLASH must be
pre-programmed with an algorithm particular to the FLASH being used.
Also, only hardware breakpoints can be set in FLASH, but either
hardware OR software breakpoints can be set in RAM.
>
> 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.

That is normal for debugging code in ROM.

> 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.
The AXF file should be the same, but the actions taken by those two
commands are very different. Read Only Memory has to be pre-programmed
before you start debugging. When you "Load debug symbol" you are not
doing anything to the target chip, you are just reading the symbol
table from the AXF file and placing it into your debuggers memory.
When you "Load image" you are extracting the executable code from the
AXF file and downloading it to the target. You can do that when the
target memory is writable, other wise the target has to be
pre-programmed with an algorithm applicable to the FLASH being used,
and then you just need to get the symbol table into the debugger.

>
> I am not sure whether "Load image" is used for debug "program run in
> SDRAM"

You can use "Load image" on any writable memory.
It has been a long time since I used MultiICE, but the basic
principles are the same for any debugger. That is, you need a symbol
table in the debugger, and you need code in the target, and the FLASH
needs to be pre-programmed with an algorithm applicable to the FLASH
being used.

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

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

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

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

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

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

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