Hi

I am trying to run a very simple program, based on the startup.s and
link commands detailed in the excellent tutorial by James Lynch. I
can flash the .bin file correctly. However, when I run a debug
session in Eclipse (I am using OpenOCD), it immediately stops at PC
0x10 (SWI) and stays there...obviously since the handler is a
while(1) loop. If I change the handler to do something, I can step
through it OK. My problem is stopping it from getting into the SWI
state in the first place; I can't understand why it's getting there.

Any suggestions would be very welcome.

John Start a New Thread

Hello John,

address 0x10 is the location of the data abort handler. Can you check the
state your target is in (CPSR value)?

Regards,

Dominic

On Sunday 01 July 2007 14:41:46 john857162 wrote:
> Hi
>
> I am trying to run a very simple program, based on the startup.s and
> link commands detailed in the excellent tutorial by James Lynch. I
> can flash the .bin file correctly. However, when I run a debug
> session in Eclipse (I am using OpenOCD), it immediately stops at PC
> 0x10 (SWI) and stays there...obviously since the handler is a
> while(1) loop. If I change the handler to do something, I can step
> through it OK. My problem is stopping it from getting into the SWI
> state in the first place; I can't understand why it's getting there.
>
> Any suggestions would be very welcome.
>
> John Start a New Thread

Hello Dominic

The value of CPSR at this point is 0x600000d3. I have been doing
some more research also and I think that the checkum might not have
been calculated correctly (the one that goes at 0x14). I am using
OpenOCD, and the .cfg file that I am using has the line

flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14765 calc_checksum

However, I am flashing the device using the telnet connect at 4444,
so am not sure whether this will have been programmed. I do not have
the facility to program via the serial port, so am using an Olimex
ARM-USB-OCD pod and a JTAG connection.

Thanks,
John

--- In l..., Dominic Rath wrote:
>
> Hello John,
>
> address 0x10 is the location of the data abort handler. Can you
check the
> state your target is in (CPSR value)?
>
> Regards,
>
> Dominic
>
> On Sunday 01 July 2007 14:41:46 john857162 wrote:
> > Hi
> >
> > I am trying to run a very simple program, based on the startup.s
and
> > link commands detailed in the excellent tutorial by James Lynch.
I
> > can flash the .bin file correctly. However, when I run a debug
> > session in Eclipse (I am using OpenOCD), it immediately stops at
PC
> > 0x10 (SWI) and stays there...obviously since the handler is a
> > while(1) loop. If I change the handler to do something, I can
step
> > through it OK. My problem is stopping it from getting into the
SWI
> > state in the first place; I can't understand why it's getting
there.
> >
> > Any suggestions would be very welcome.
> >
> > John
> Start a New Thread

john857162 wrote:
>
> Hello Dominic
>
> The value of CPSR at this point is 0x600000d3. I have been doing
> some more research also and I think that the checkum might not have
> been calculated correctly (the one that goes at 0x14). I am using
> OpenOCD, and the .cfg file that I am using has the line
>
I doubt it. If the checksum was wrong you should not have reached an
Abort situation. If your checksum is wrong, then the internal bootstrap
ROM would have placed you into the ISP download mode.
> flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14765 calc_checksum
>
> However, I am flashing the device using the telnet connect at 4444,
> so am not sure whether this will have been programmed. I do not have
> the facility to program via the serial port, so am using an Olimex
> ARM-USB-OCD pod and a JTAG connection.
>

With a data abort, the link register (r13) should be pointing at the
instruction where the Abort was thrown. Look at the link register (lr /
r13) and then check your map file or .lss file to see what instruction
it was executing and what function it was in when it threw the Abort.

Alternatively, you can "divide and conquer". IOW, stop the program at
main(), then step the program over the function calls until it throws
the Abort (you'll know when that happens). Then you know about where
the problem in your code lies.

Writing code is a small part of building a program, IMO, the major
skill needed is how to find out what is wrong with the code that you
write: debugging it.

OpenOCD is merely a mechanism to interface to the internal JTAG inside
the ARM controller. Dominic, and others, can help make sure your
OpenOCD scripts are properly setup to describe the core that is Under
Test (Joint Test / Action Group == JTAG).
Regards,

TomW

> Thanks,
> John
>
> --- In lpc2000@yahoogroups .com ,
> Dominic Rath wrote:
> >
> > Hello John,
> >
> > address 0x10 is the location of the data abort handler. Can you
> check the
> > state your target is in (CPSR value)?
> >
> > Regards,
> >
> > Dominic
> >
> > On Sunday 01 July 2007 14:41:46 john857162 wrote:
> > > Hi
> > >
> > > I am trying to run a very simple program, based on the startup.s
> and
> > > link commands detailed in the excellent tutorial by James Lynch.
> I
> > > can flash the .bin file correctly. However, when I run a debug
> > > session in Eclipse (I am using OpenOCD), it immediately stops at
> PC
> > > 0x10 (SWI) and stays there...obviously since the handler is a
> > > while(1) loop. If I change the handler to do something, I can
> step
> > > through it OK. My problem is stopping it from getting into the
> SWI
> > > state in the first place; I can't understand why it's getting
> there.
> > >
> > > Any suggestions would be very welcome.
> > >
> > > John
> >
--
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

"john857162" writes:

> flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14765 calc_checksum

Doesn't the LPC2103 have just 32KB of flash? If so, shouldn't the
0x40000 above be 0x8000 ?

> However, I am flashing the device using the telnet connect at 4444,
> so am not sure whether this will have been programmed. I do not have
> the facility to program via the serial port, so am using an Olimex
> ARM-USB-OCD pod and a JTAG connection.

Are you erasing it before trying to program it? Suppose your program
needs 2 sectors,

telnet 4444
> flash erase 0 0 1 (erase sectors 0 through 1)
> flash write 0 xxx.bin 0 (program it)
--
Frank Start a New Thread

--- In l..., Tom Walsh wrote:
>
> john857162 wrote:
> >
> > Hello Dominic
> >
> > The value of CPSR at this point is 0x600000d3. I have been doing
> > some more research also and I think that the checkum might not have
> > been calculated correctly (the one that goes at 0x14). I am using
> > OpenOCD, and the .cfg file that I am using has the line
> >
> I doubt it. If the checksum was wrong you should not have reached an
> Abort situation. If your checksum is wrong, then the internal
bootstrap
> ROM would have placed you into the ISP download mode.
What I find a bit interesting in john857162's question is that he
indicated that his code is getting stuck in an endless loop at the
Data Abort handler, but the information that he gave concerning the
contents of the CPSR doe not indicate the core being in Data Abort
mode. If I decoded the CPSR status bits correctly, the core appears
to be in ARM Supervisor mode with interrupts disabled? Is it possible
some faulty code simply branched to the Data Abort handler?

--Dave Start a New Thread

--- In l..., "derbaier" wrote:
>
> --- In l..., Tom Walsh wrote:
> >
> > john857162 wrote:
> > >
> > > Hello Dominic
> > >
> > > The value of CPSR at this point is 0x600000d3. I have been doing
> > > some more research also and I think that the checkum might not
have
> > > been calculated correctly (the one that goes at 0x14). I am
using
> > > OpenOCD, and the .cfg file that I am using has the line
> > >
> >
> >
> > I doubt it. If the checksum was wrong you should not have
reached an
> > Abort situation. If your checksum is wrong, then the internal
> bootstrap
> > ROM would have placed you into the ISP download mode.
> >
> >
> What I find a bit interesting in john857162's question is that he
> indicated that his code is getting stuck in an endless loop at the
> Data Abort handler, but the information that he gave concerning the
> contents of the CPSR doe not indicate the core being in Data Abort
> mode. If I decoded the CPSR status bits correctly, the core appears
> to be in ARM Supervisor mode with interrupts disabled? Is it
possible
> some faulty code simply branched to the Data Abort handler?
>
> --Dave
>

If it has gone through one of the exception vectors in an unexplained
way, one typcial cause is just jumping there, and a typical cause of
that is a corrupted or incorrect stack (i.e. restored link register
is in fact a low value integer).

I'd check that the stacks and stack pointers are OK.

Brendan Start a New Thread

It looks like I am having some problems with my link. I have
followed the examples, but it doesnt look right to me. My link .cmd
file contains the following....
/* identify the Entry Point */

ENTRY(_startup)

/* specify the LPC2103 memory areas */

MEMORY
{
flash : ORIGIN = 0, LENGTH = 32K
ram_isp_low(A) : ORIGIN = 0x40000040, LENGTH = 224
ram : ORIGIN = 0x40000120, LENGTH = 7872
ram_isp_high(A) : ORIGIN = 0x40001FE0, LENGTH = 32 }

/* define a global symbol _stack_end */

_stack_end = 0x40001FDC;

/* now define the output sections */

SECTIONS
{
. = 0;
/* set location counter to address zero */

startup : { *(.startup)} >flash /* the startup code
goes into FLASH */

.text :
/* collect all sections that should go into FLASH after
startup */
{
*(.text) /* all .text sections (code) */
*(.rodata) /* all .rodata sections (constants, strings,
etc.) */
*(.rodata*) /* all .rodata* sections 8?
*(.glue_7)
*(.glue_7t)
_etext = .;
} >flash
/* put all the above into FLASH */
.data :
/* collect all initialized .data sections that go in RAM */
{
_data = .;
/* create a global symbol marking the start of the .data
section */
*(.data)
/* all .data sections */
_edata = .;
/* define a global symbol marking the end of the .data
section */
} >ram AT >flash

/* put all the above into RAM (but load the LMA copy into FLASH) */

.bss :
/* collect all uninit .bss sections that go into RAM */
{
_bss_start = .;
/* define a global symbol marking the start of the .bss section */
*(.bss)
/* all .bss sections */
} >ram

/* put all the above in RAM (it will be cleared in the
startup code */

. = ALIGN(4); /*
advance location counter to the next 32-bit boundary */
_bss_end = . ; /*
define a global symbol marking the end of the .bss section */
}
_end = .;
/* define a global symbol marking the end of application RAM
*/

(sorry for the tabs....)

However, my MAP file looks like this..... (the top of it anyway...)

Memory Configuration

Name Origin Length Attributes
flash 0x00000000 0x00008000
ram_isp_low 0x40000040 0x000000e0 a
ram 0x40000120 0x00001ec0
ram_isp_high 0x40001fe0 0x00000020 a
*default* 0x00000000 0xffffffff

Linker script and memory map

0x40001fdc _stack_end = 0x40001fdc
0x00000000 . = 0x0

startup
*(.startup)

.text 0x00000000 0x780
*(.text)
.text 0x00000000 0x28 appInterrupts.o
0x00000014 UNDEF_Routine
0x00000000 SWI_Routine
.text 0x00000028 0x34 appMain.o
0x00000028 main
.text 0x0000005c 0x0 dbgAsserts.o
As you can see, the SWI_Routine and .startup share the same address.
I have looked at other examples of lpc2103 map files and this isnt
the case...any help would be *much* appreciated.

John

--- In l..., "Brendan
Murphy" wrote:
>
> --- In l..., "derbaier" wrote:
> >
> > --- In l..., Tom Walsh wrote:
> > >
> > > john857162 wrote:
> > > >
> > > > Hello Dominic
> > > >
> > > > The value of CPSR at this point is 0x600000d3. I have been
doing
> > > > some more research also and I think that the checkum might
not
> have
> > > > been calculated correctly (the one that goes at 0x14). I am
> using
> > > > OpenOCD, and the .cfg file that I am using has the line
> > > >
> > >
> > >
> > > I doubt it. If the checksum was wrong you should not have
> reached an
> > > Abort situation. If your checksum is wrong, then the internal
> > bootstrap
> > > ROM would have placed you into the ISP download mode.
> > >
> > >
> > What I find a bit interesting in john857162's question is that he
> > indicated that his code is getting stuck in an endless loop at the
> > Data Abort handler, but the information that he gave concerning
the
> > contents of the CPSR doe not indicate the core being in Data Abort
> > mode. If I decoded the CPSR status bits correctly, the core
appears
> > to be in ARM Supervisor mode with interrupts disabled? Is it
> possible
> > some faulty code simply branched to the Data Abort handler?
> >
> > --Dave
> > If it has gone through one of the exception vectors in an
unexplained
> way, one typcial cause is just jumping there, and a typical cause
of
> that is a corrupted or incorrect stack (i.e. restored link register
> is in fact a low value integer).
>
> I'd check that the stacks and stack pointers are OK.
>
> Brendan
> Start a New Thread

I'm not sure there isn't something wrong with the linker script but I
don't see it right off.

But, I would be willing to bet there is something wrong with your
startup code (crt.S) or your makefile.

At some point in the memory map, I would expect to see all of the
interrupt entry points defined. I suppose you could have sent them
all to the same place but that isn't the way a 'standard' crt.S would
handle it.

Why don't you ZIP your project files (ALL of them) and stuff the
archive in the Files section.

Richard

--- In l..., "john857162" wrote:
>
> It looks like I am having some problems with my link. I have
> followed the examples, but it doesnt look right to me. My link .cmd
> file contains the following....
> /* identify the Entry Point */
>
> ENTRY(_startup)
>
> /* specify the LPC2103 memory areas */
>
> MEMORY
> {
> flash : ORIGIN = 0, LENGTH = 32K
> ram_isp_low(A) : ORIGIN = 0x40000040, LENGTH = 224
> ram : ORIGIN = 0x40000120, LENGTH = 7872
> ram_isp_high(A) : ORIGIN = 0x40001FE0, LENGTH = 32 }
>
> /* define a global symbol _stack_end */
>
> _stack_end = 0x40001FDC;
>
> /* now define the output sections */
>
> SECTIONS
> {
> . = 0;
> /* set location counter to address zero */
>
> startup : { *(.startup)} >flash /* the startup code
> goes into FLASH */
>
>
> .text :
> /* collect all sections that should go into FLASH after
> startup */
> {
> *(.text) /* all .text sections (code) */
> *(.rodata) /* all .rodata sections (constants, strings,
> etc.) */
> *(.rodata*) /* all .rodata* sections 8?
> *(.glue_7)
> *(.glue_7t)
> _etext = .;
> } >flash
> /* put all the above into FLASH */
> .data :
> /* collect all initialized .data sections that go in RAM */
> {
> _data = .;
> /* create a global symbol marking the start of the .data
> section */
> *(.data)
> /* all .data sections */
> _edata = .;
> /* define a global symbol marking the end of the .data
> section */
> } >ram AT >flash
>
> /* put all the above into RAM (but load the LMA copy into FLASH) */
>
> .bss :
> /* collect all uninit .bss sections that go into RAM */
> {
> _bss_start = .;
> /* define a global symbol marking the start of the .bss section */
> *(.bss)
> /* all .bss sections */
> } >ram
>
> /* put all the above in RAM (it will be cleared in the
> startup code */
>
> . = ALIGN(4); /*
> advance location counter to the next 32-bit boundary */
> _bss_end = . ; /*
> define a global symbol marking the end of the .bss section */
> }
> _end = .;
> /* define a global symbol marking the end of application RAM
> */
>
>
> (sorry for the tabs....)
>
> However, my MAP file looks like this..... (the top of it anyway...)
>
> Memory Configuration
>
> Name Origin Length Attributes
> flash 0x00000000 0x00008000
> ram_isp_low 0x40000040 0x000000e0 a
> ram 0x40000120 0x00001ec0
> ram_isp_high 0x40001fe0 0x00000020 a
> *default* 0x00000000 0xffffffff
>
> Linker script and memory map
>
> 0x40001fdc _stack_end = 0x40001fdc
> 0x00000000 . = 0x0
>
> startup
> *(.startup)
>
> .text 0x00000000 0x780
> *(.text)
> .text 0x00000000 0x28 appInterrupts.o
> 0x00000014 UNDEF_Routine
> 0x00000000 SWI_Routine
> .text 0x00000028 0x34 appMain.o
> 0x00000028 main
> .text 0x0000005c 0x0 dbgAsserts.o
> As you can see, the SWI_Routine and .startup share the same address.
> I have looked at other examples of lpc2103 map files and this isnt
> the case...any help would be *much* appreciated.
>
> John
>
> --- In l..., "Brendan
> Murphy" wrote:
> >
> > --- In l..., "derbaier" wrote:
> > >
> > > --- In l..., Tom Walsh wrote:
> > > >
> > > > john857162 wrote:
> > > > >
> > > > > Hello Dominic
> > > > >
> > > > > The value of CPSR at this point is 0x600000d3. I have been
> doing
> > > > > some more research also and I think that the checkum might
> not
> > have
> > > > > been calculated correctly (the one that goes at 0x14). I am
> > using
> > > > > OpenOCD, and the .cfg file that I am using has the line
> > > > >
> > > >
> > > >
> > > > I doubt it. If the checksum was wrong you should not have
> > reached an
> > > > Abort situation. If your checksum is wrong, then the internal
> > > bootstrap
> > > > ROM would have placed you into the ISP download mode.
> > > >
> > > >
> > > What I find a bit interesting in john857162's question is that he
> > > indicated that his code is getting stuck in an endless loop at the
> > > Data Abort handler, but the information that he gave concerning
> the
> > > contents of the CPSR doe not indicate the core being in Data Abort
> > > mode. If I decoded the CPSR status bits correctly, the core
> appears
> > > to be in ARM Supervisor mode with interrupts disabled? Is it
> > possible
> > > some faulty code simply branched to the Data Abort handler?
> > >
> > > --Dave
> > >
> >
> > If it has gone through one of the exception vectors in an
> unexplained
> > way, one typcial cause is just jumping there, and a typical cause
> of
> > that is a corrupted or incorrect stack (i.e. restored link register
> > is in fact a low value integer).
> >
> > I'd check that the stacks and stack pointers are OK.
> >
> > Brendan
> Start a New Thread