[ECOS] arm7 lpc2xxx abort data exception

[ECOS] arm7 lpc2xxx abort data exception

[Jean-David Vuillemain]

hi,

i have been working with ecos for a couple of months now. I had no
problem at all with a 8 months old repository source files and my own
port for my target board. After some problem with my working
environment  and updating the ecos source files, i can't have my old
work and my new  code running on the board.
It seems that my code always go through the same steps and finishes by
 an exception abort data.

Here is the code where it fails:
0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
0x80020074 <start+4>:  ldr r1, [r0]
0x80020078 <start+8>:  cmp r1, #0    ; 0x0
0x8002007c <start+12>: bne 0x80020078 <start+8>
0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
0x80020084 <start+20>: str r1, [r0]
0x80020088 <start+24>: mov r0, #0    ; 0x0
0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
<.__exception_handlers>
0x80020090 <start+32>: cmp r7, #19    ; 0x13
0x80020094 <start+36>: beq 0x800200a0 <start+48>
0x80020098 <start+40>: ldr r2, [r1, #40]
0x8002009c <start+44>: str r2, [r0, #40]
0x800200a0 <start+48>: ldr r2, [r1, #24]
0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
old and new programs
It ends up in an abort data:
0x00000010 swp             r1, r3, [r2]

Someone has a hint to solve this problem??

Thanks in advance.

Jean-David

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Andrew Lunn]

On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
> hi,
> 
> i have been working with ecos for a couple of months now. I had no
> problem at all with a 8 months old repository source files and my own
> port for my target board. After some problem with my working
> environment  and updating the ecos source files, i can't have my old
> work and my new  code running on the board.
> It seems that my code always go through the same steps and finishes by
>  an exception abort data.
> 
> Here is the code where it fails:
> 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
> 0x80020074 <start+4>:  ldr r1, [r0]
> 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
> 0x8002007c <start+12>: bne 0x80020078 <start+8>
> 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
> 0x80020084 <start+20>: str r1, [r0]
> 0x80020088 <start+24>: mov r0, #0    ; 0x0
> 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
> <.__exception_handlers>
> 0x80020090 <start+32>: cmp r7, #19    ; 0x13
> 0x80020094 <start+36>: beq 0x800200a0 <start+48>
> 0x80020098 <start+40>: ldr r2, [r1, #40]
> 0x8002009c <start+44>: str r2, [r0, #40]
> 0x800200a0 <start+48>: ldr r2, [r1, #24]
> 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
> old and new programs
> It ends up in an abort data:
> 0x00000010 swp             r1, r3, [r2]

What is the value of r0? You should be able to look at the exception
bank of registers and see a value. Is it legal, does RAM/FLASH/IO
exist there etc.

The fact you are in exception handlers is not good anything. It
suggests something else has gone wrong. Have you checked your stacks
are big enough. It seems like 75% of random crashes are stack
overflows.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Jean-David Vuillemain]

hi,
The value of r0 is 0 just before the execution of <start+52>. The
abort data exception tells that the address where it can't read is
0xE59FF018 wich is a reserved address.

For the stack I have no idea. I will change the stack value and see if
it is making it work.

thanks

JD

2008/1/24, Andrew Lunn <andrew@lunn.ch>:
> On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
> > hi,
> >
> > i have been working with ecos for a couple of months now. I had no
> > problem at all with a 8 months old repository source files and my own
> > port for my target board. After some problem with my working
> > environment  and updating the ecos source files, i can't have my old
> > work and my new  code running on the board.
> > It seems that my code always go through the same steps and finishes by
> >  an exception abort data.
> >
> > Here is the code where it fails:
> > 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
> > 0x80020074 <start+4>:  ldr r1, [r0]
> > 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
> > 0x8002007c <start+12>: bne 0x80020078 <start+8>
> > 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
> > 0x80020084 <start+20>: str r1, [r0]
> > 0x80020088 <start+24>: mov r0, #0    ; 0x0
> > 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
> > <.__exception_handlers>
> > 0x80020090 <start+32>: cmp r7, #19    ; 0x13
> > 0x80020094 <start+36>: beq 0x800200a0 <start+48>
> > 0x80020098 <start+40>: ldr r2, [r1, #40]
> > 0x8002009c <start+44>: str r2, [r0, #40]
> > 0x800200a0 <start+48>: ldr r2, [r1, #24]
> > 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
> > old and new programs
> > It ends up in an abort data:
> > 0x00000010 swp             r1, r3, [r2]
>
> What is the value of r0? You should be able to look at the exception
> bank of registers and see a value. Is it legal, does RAM/FLASH/IO
> exist there etc.
>
> The fact you are in exception handlers is not good anything. It
> suggests something else has gone wrong. Have you checked your stacks
> are big enough. It seems like 75% of random crashes are stack
> overflows.
>
>         Andrew
>


-- 
Jean-David Vuillemain
jdvuillemain@gmail.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Gary Thomas]

Jean-David Vuillemain wrote:
> hi,
> The value of r0 is 0 just before the execution of <start+52>. The
> abort data exception tells that the address where it can't read is
> 0xE59FF018 wich is a reserved address.
> 
> For the stack I have no idea. I will change the stack value and see if
> it is making it work.

You program is failing in the very early stages of initializing eCos.
Sadly, none of the suggestions you've seen so far (while generally
helpful) apply to your problem.

The step that's failing is where your code tries to take over the
exception handlers.  It does this by storing come pointers into
memory, starting at location 0x0.

Do you have RAM at 0x0?
What changed when up updated eCos last?

> 2008/1/24, Andrew Lunn <andrew@lunn.ch>:
>> On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
>>> hi,
>>>
>>> i have been working with ecos for a couple of months now. I had no
>>> problem at all with a 8 months old repository source files and my own
>>> port for my target board. After some problem with my working
>>> environment  and updating the ecos source files, i can't have my old
>>> work and my new  code running on the board.
>>> It seems that my code always go through the same steps and finishes by
>>>  an exception abort data.
>>>
>>> Here is the code where it fails:
>>> 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
>>> 0x80020074 <start+4>:  ldr r1, [r0]
>>> 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
>>> 0x8002007c <start+12>: bne 0x80020078 <start+8>
>>> 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
>>> 0x80020084 <start+20>: str r1, [r0]
>>> 0x80020088 <start+24>: mov r0, #0    ; 0x0
>>> 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
>>> <.__exception_handlers>
>>> 0x80020090 <start+32>: cmp r7, #19    ; 0x13
>>> 0x80020094 <start+36>: beq 0x800200a0 <start+48>
>>> 0x80020098 <start+40>: ldr r2, [r1, #40]
>>> 0x8002009c <start+44>: str r2, [r0, #40]
>>> 0x800200a0 <start+48>: ldr r2, [r1, #24]
>>> 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
>>> old and new programs
>>> It ends up in an abort data:
>>> 0x00000010 swp             r1, r3, [r2]
>> What is the value of r0? You should be able to look at the exception
>> bank of registers and see a value. Is it legal, does RAM/FLASH/IO
>> exist there etc.
>>
>> The fact you are in exception handlers is not good anything. It
>> suggests something else has gone wrong. Have you checked your stacks
>> are big enough. It seems like 75% of random crashes are stack
>> overflows.
>>
>>         Andrew
>>
> 
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Gary Thomas]

Please keep your replies on the list so that all benefit.

Jean-David Vuillemain wrote:
> There is no ram at address 0x0. This is the internal flash of the
> lpc2294 (0x00 to 0x00040000 . The internal ram is at address
> 0x40000000.
> Since the last update the only thing that has changed is the source
> files. I have seen that a few modifications were made on the lpc2xxx
> var for example. But as you said it is hapening really early, during
> the first step after a warm_reset.

If you have no RAM at 0x0, then you must have had some other changes
in your code before because the standard ARM eCos HAL expects RAM at 0.

You need to figure out what changed - hopefully you kept a copy of
what was working.

> 2008/1/25, Gary Thomas <gary@mlbassoc.com>:
>> Jean-David Vuillemain wrote:
>>> hi,
>>> The value of r0 is 0 just before the execution of <start+52>. The
>>> abort data exception tells that the address where it can't read is
>>> 0xE59FF018 wich is a reserved address.
>>>
>>> For the stack I have no idea. I will change the stack value and see if
>>> it is making it work.
>> You program is failing in the very early stages of initializing eCos.
>> Sadly, none of the suggestions you've seen so far (while generally
>> helpful) apply to your problem.
>>
>> The step that's failing is where your code tries to take over the
>> exception handlers.  It does this by storing come pointers into
>> memory, starting at location 0x0.
>>
>> Do you have RAM at 0x0?
>> What changed when up updated eCos last?
>>
>>> 2008/1/24, Andrew Lunn <andrew@lunn.ch>:
>>>> On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
>>>>> hi,
>>>>>
>>>>> i have been working with ecos for a couple of months now. I had no
>>>>> problem at all with a 8 months old repository source files and my own
>>>>> port for my target board. After some problem with my working
>>>>> environment  and updating the ecos source files, i can't have my old
>>>>> work and my new  code running on the board.
>>>>> It seems that my code always go through the same steps and finishes by
>>>>>  an exception abort data.
>>>>>
>>>>> Here is the code where it fails:
>>>>> 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
>>>>> 0x80020074 <start+4>:  ldr r1, [r0]
>>>>> 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
>>>>> 0x8002007c <start+12>: bne 0x80020078 <start+8>
>>>>> 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
>>>>> 0x80020084 <start+20>: str r1, [r0]
>>>>> 0x80020088 <start+24>: mov r0, #0    ; 0x0
>>>>> 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
>>>>> <.__exception_handlers>
>>>>> 0x80020090 <start+32>: cmp r7, #19    ; 0x13
>>>>> 0x80020094 <start+36>: beq 0x800200a0 <start+48>
>>>>> 0x80020098 <start+40>: ldr r2, [r1, #40]
>>>>> 0x8002009c <start+44>: str r2, [r0, #40]
>>>>> 0x800200a0 <start+48>: ldr r2, [r1, #24]
>>>>> 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
>>>>> old and new programs
>>>>> It ends up in an abort data:
>>>>> 0x00000010 swp             r1, r3, [r2]
>>>> What is the value of r0? You should be able to look at the exception
>>>> bank of registers and see a value. Is it legal, does RAM/FLASH/IO
>>>> exist there etc.
>>>>
>>>> The fact you are in exception handlers is not good anything. It
>>>> suggests something else has gone wrong. Have you checked your stacks
>>>> are big enough. It seems like 75% of random crashes are stack
>>>> overflows.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Sergei Gavrikov]

On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
> hi,
> 
> i have been working with ecos for a couple of months now. I had no
> problem at all with a 8 months old repository source files and my own
> port for my target board. After some problem with my working
> environment  and updating the ecos source files, i can't have my old
> work and my new  code running on the board.

Working with lpc2xxx targets I update eCos repository every week.  Did
you try to build eCos with a tracing support? Import 2 lines the below
with ecosconfig and rebuild eCos

cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
cdl_option CYGDBG_USE_TRACING {user_value 1};

Can you run your application in GDB as

b cyg_start
b cyg_assert_fail
c
c

I wonder, Did you get same assertion?

ASSERT FAIL: <1>lpc2xxx_misc.c[359]hal_interrupt_configure() Invalid vector


Sergei

> It seems that my code always go through the same steps and finishes by
>  an exception abort data.
> 
> Here is the code where it fails:
> 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
> 0x80020074 <start+4>:  ldr r1, [r0]
> 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
> 0x8002007c <start+12>: bne 0x80020078 <start+8>
> 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
> 0x80020084 <start+20>: str r1, [r0]
> 0x80020088 <start+24>: mov r0, #0    ; 0x0
> 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
> <.__exception_handlers>
> 0x80020090 <start+32>: cmp r7, #19    ; 0x13
> 0x80020094 <start+36>: beq 0x800200a0 <start+48>
> 0x80020098 <start+40>: ldr r2, [r1, #40]
> 0x8002009c <start+44>: str r2, [r0, #40]
> 0x800200a0 <start+48>: ldr r2, [r1, #24]
> 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
> old and new programs
> It ends up in an abort data:
> 0x00000010 swp             r1, r3, [r2]
> 
> Someone has a hint to solve this problem??
> 
> Thanks in advance.
> 
> Jean-David
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Jean-David Vuillemain]

Yes i use a mixture of tool in fact...

"Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?"
Could you be more explicit please.

JD
2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> On Fri, Jan 25, 2008 at 10:21:39AM -0800, Jean-David Vuillemain wrote:
> > I can run my application with GDB but the breakpoints you point out
> > are not reachable. The program goes straight to the data abort at
> > 0x00000010 after a few instructions.
> > I didn't get any assertion message.
>
> I have another question, Is it possible that you use a mixture of tools?
> Is your GNU toolchain a home-cooked stuff? Does the error occur with
> GCC-3.2.1? If you build eCos with a recent tolchain, it could be that
> you did modify CYGBLD_GLOBAL_CFLAGS and your startup become a broken...
> Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?
>
> Sergei
>
> > 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > > On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
> > > > hi,
> > > >
> > > > i have been working with ecos for a couple of months now. I had no
> > > > problem at all with a 8 months old repository source files and my own
> > > > port for my target board. After some problem with my working
> > > > environment  and updating the ecos source files, i can't have my old
> > > > work and my new  code running on the board.
> > >
> > > Working with lpc2xxx targets I update eCos repository every week.  Did
> > > you try to build eCos with a tracing support? Import 2 lines the below
> > > with ecosconfig and rebuild eCos
> > >
> > > cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
> > > cdl_option CYGDBG_USE_TRACING {user_value 1};
> > >
> > > Can you run your application in GDB as
> > >
> > > b cyg_start
> > > b cyg_assert_fail
> > > c
> > > c
> > >
> > > I wonder, Did you get same assertion?
> > >
> > > ASSERT FAIL: <1>lpc2xxx_misc.c[359]hal_interrupt_configure() Invalid vector
> > >
> > >
> > > Sergei
> > >
> > > > It seems that my code always go through the same steps and finishes by
> > > >  an exception abort data.
> > > >
> > > > Here is the code where it fails:
> > > > 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
> > > > 0x80020074 <start+4>:  ldr r1, [r0]
> > > > 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
> > > > 0x8002007c <start+12>: bne 0x80020078 <start+8>
> > > > 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
> > > > 0x80020084 <start+20>: str r1, [r0]
> > > > 0x80020088 <start+24>: mov r0, #0    ; 0x0
> > > > 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
> > > > <.__exception_handlers>
> > > > 0x80020090 <start+32>: cmp r7, #19    ; 0x13
> > > > 0x80020094 <start+36>: beq 0x800200a0 <start+48>
> > > > 0x80020098 <start+40>: ldr r2, [r1, #40]
> > > > 0x8002009c <start+44>: str r2, [r0, #40]
> > > > 0x800200a0 <start+48>: ldr r2, [r1, #24]
> > > > 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
> > > > old and new programs
> > > > It ends up in an abort data:
> > > > 0x00000010 swp             r1, r3, [r2]
> > > >
> > > > Someone has a hint to solve this problem??
> > > >
> > > > Thanks in advance.
> > > >
> > > > Jean-David
> > > >
> > > > --
> > > > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > > > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> > >
> >
> >
> > --
> > Jean-David Vuillemain
> > jdvuillemain@gmail.com
>


-- 
Jean-David Vuillemain
jdvuillemain@gmail.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Sergei Gavrikov]

On Fri, Jan 25, 2008 at 01:55:06PM -0800, Jean-David Vuillemain wrote:
> Yes i use a mixture of tool in fact...
> 
> "Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?"
> Could you be more explicit please.

I wonder, will you get a hang on a startup stage when you'll build eCos
with GNU toolchain from public FTP (a.k.a eCosCentric tools)? And what
about behaviors of built application for ROM startup? Does that hang
too?

Sergei

> JD
> 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > On Fri, Jan 25, 2008 at 10:21:39AM -0800, Jean-David Vuillemain wrote:
> > > I can run my application with GDB but the breakpoints you point out
> > > are not reachable. The program goes straight to the data abort at
> > > 0x00000010 after a few instructions.
> > > I didn't get any assertion message.
> >
> > I have another question, Is it possible that you use a mixture of tools?
> > Is your GNU toolchain a home-cooked stuff? Does the error occur with
> > GCC-3.2.1? If you build eCos with a recent tolchain, it could be that
> > you did modify CYGBLD_GLOBAL_CFLAGS and your startup become a broken...
> > Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?
> >
> > Sergei
> >
> > > 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > > > On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
> > > > > hi,
> > > > >
> > > > > i have been working with ecos for a couple of months now. I had no
> > > > > problem at all with a 8 months old repository source files and my own
> > > > > port for my target board. After some problem with my working
> > > > > environment  and updating the ecos source files, i can't have my old
> > > > > work and my new  code running on the board.
> > > >
> > > > Working with lpc2xxx targets I update eCos repository every week.  Did
> > > > you try to build eCos with a tracing support? Import 2 lines the below
> > > > with ecosconfig and rebuild eCos
> > > >
> > > > cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
> > > > cdl_option CYGDBG_USE_TRACING {user_value 1};
> > > >
> > > > Can you run your application in GDB as
> > > >
> > > > b cyg_start
> > > > b cyg_assert_fail
> > > > c
> > > > c
> > > >
> > > > I wonder, Did you get same assertion?
> > > >
> > > > ASSERT FAIL: <1>lpc2xxx_misc.c[359]hal_interrupt_configure() Invalid vector
> > > >
> > > >
> > > > Sergei
> > > >
> > > > > It seems that my code always go through the same steps and finishes by
> > > > >  an exception abort data.
> > > > >
> > > > > Here is the code where it fails:
> > > > > 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
> > > > > 0x80020074 <start+4>:  ldr r1, [r0]
> > > > > 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
> > > > > 0x8002007c <start+12>: bne 0x80020078 <start+8>
> > > > > 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
> > > > > 0x80020084 <start+20>: str r1, [r0]
> > > > > 0x80020088 <start+24>: mov r0, #0    ; 0x0
> > > > > 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
> > > > > <.__exception_handlers>
> > > > > 0x80020090 <start+32>: cmp r7, #19    ; 0x13
> > > > > 0x80020094 <start+36>: beq 0x800200a0 <start+48>
> > > > > 0x80020098 <start+40>: ldr r2, [r1, #40]
> > > > > 0x8002009c <start+44>: str r2, [r0, #40]
> > > > > 0x800200a0 <start+48>: ldr r2, [r1, #24]
> > > > > 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
> > > > > old and new programs
> > > > > It ends up in an abort data:
> > > > > 0x00000010 swp             r1, r3, [r2]
> > > > >
> > > > > Someone has a hint to solve this problem??
> > > > >
> > > > > Thanks in advance.
> > > > >
> > > > > Jean-David
> > > > >
> > > > > --
> > > > > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > > > > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> > > >
> > >
> > >
> > > --
> > > Jean-David Vuillemain
> > > jdvuillemain@gmail.com
> >
> 
> 
> -- 
> Jean-David Vuillemain
> jdvuillemain@gmail.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Tom Deconinck]

Hi,

Could it be that you need to do some memory remapping to get the
exception vectors at the right address (they have to be located at
address 0)? I have no idea if the LPC requires this, so just a quick
thought.

I had a similar issue trying to run a RAM image on the Atmel ARM7
(AT91SAM7SE)  based cpu, in my case the problem was caused because the
SRAM-Flash remap code that wasn't in the RAM image startup sequence.

Tom

On Jan 25, 2008 11:06 PM, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> On Fri, Jan 25, 2008 at 01:55:06PM -0800, Jean-David Vuillemain wrote:
> > Yes i use a mixture of tool in fact...
> >
> > "Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?"
> > Could you be more explicit please.
>
> I wonder, will you get a hang on a startup stage when you'll build eCos
> with GNU toolchain from public FTP (a.k.a eCosCentric tools)? And what
> about behaviors of built application for ROM startup? Does that hang
> too?
>
> Sergei
>
>
> > JD
> > 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > > On Fri, Jan 25, 2008 at 10:21:39AM -0800, Jean-David Vuillemain wrote:
> > > > I can run my application with GDB but the breakpoints you point out
> > > > are not reachable. The program goes straight to the data abort at
> > > > 0x00000010 after a few instructions.
> > > > I didn't get any assertion message.
> > >
> > > I have another question, Is it possible that you use a mixture of tools?
> > > Is your GNU toolchain a home-cooked stuff? Does the error occur with
> > > GCC-3.2.1? If you build eCos with a recent tolchain, it could be that
> > > you did modify CYGBLD_GLOBAL_CFLAGS and your startup become a broken...
> > > Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?
> > >
> > > Sergei
> > >
> > > > 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > > > > On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
> > > > > > hi,
> > > > > >
> > > > > > i have been working with ecos for a couple of months now. I had no
> > > > > > problem at all with a 8 months old repository source files and my own
> > > > > > port for my target board. After some problem with my working
> > > > > > environment  and updating the ecos source files, i can't have my old
> > > > > > work and my new  code running on the board.
> > > > >
> > > > > Working with lpc2xxx targets I update eCos repository every week.  Did
> > > > > you try to build eCos with a tracing support? Import 2 lines the below
> > > > > with ecosconfig and rebuild eCos
> > > > >
> > > > > cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
> > > > > cdl_option CYGDBG_USE_TRACING {user_value 1};
> > > > >
> > > > > Can you run your application in GDB as
> > > > >
> > > > > b cyg_start
> > > > > b cyg_assert_fail
> > > > > c
> > > > > c
> > > > >
> > > > > I wonder, Did you get same assertion?
> > > > >
> > > > > ASSERT FAIL: <1>lpc2xxx_misc.c[359]hal_interrupt_configure() Invalid vector
> > > > >
> > > > >
> > > > > Sergei
> > > > >
> > > > > > It seems that my code always go through the same steps and finishes by
> > > > > >  an exception abort data.
> > > > > >
> > > > > > Here is the code where it fails:
> > > > > > 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
> > > > > > 0x80020074 <start+4>:  ldr r1, [r0]
> > > > > > 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
> > > > > > 0x8002007c <start+12>: bne 0x80020078 <start+8>
> > > > > > 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
> > > > > > 0x80020084 <start+20>: str r1, [r0]
> > > > > > 0x80020088 <start+24>: mov r0, #0    ; 0x0
> > > > > > 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
> > > > > > <.__exception_handlers>
> > > > > > 0x80020090 <start+32>: cmp r7, #19    ; 0x13
> > > > > > 0x80020094 <start+36>: beq 0x800200a0 <start+48>
> > > > > > 0x80020098 <start+40>: ldr r2, [r1, #40]
> > > > > > 0x8002009c <start+44>: str r2, [r0, #40]
> > > > > > 0x800200a0 <start+48>: ldr r2, [r1, #24]
> > > > > > 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
> > > > > > old and new programs
> > > > > > It ends up in an abort data:
> > > > > > 0x00000010 swp             r1, r3, [r2]
> > > > > >
> > > > > > Someone has a hint to solve this problem??
> > > > > >
> > > > > > Thanks in advance.
> > > > > >
> > > > > > Jean-David
> > > > > >
> > > > > > --
> > > > > > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > > > > > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> > > > >
> > > >
> > > >
> > > > --
> > > > Jean-David Vuillemain
> > > > jdvuillemain@gmail.com
> > >
> >
> >
> > --
> > Jean-David Vuillemain
> > jdvuillemain@gmail.com
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Alergent]

Hi,

I have LPC2290 and had very similar problem at the very beginning.

The problem was caused by part of the code in
/packages/hal/arm/arch/current/src/vectors.S and my configuration settings.

There is a ".global __exception_handles" part where in case 
CYGSEM_HAL_ROM_RESET_USES_JUMP is defined short jump (b reset_vector) is 
used.

In my case it was defined and I had a short jump... Because CPU starts 
with interrupt vectors remapped to address 0 and the rest is residing 
somewhere in memory (address depends on boot configuration) long jump 
(ldr pc,.reset_vetor) is required.

Check whether CYGSEM_HAL_ROM_RESET_USES_JUMP is defined and undefine it. 
Hopefully this will help.

Greetings
Tomasz
> Hi,
>
> Could it be that you need to do some memory remapping to get the
> exception vectors at the right address (they have to be located at
> address 0)? I have no idea if the LPC requires this, so just a quick
> thought.
>
> I had a similar issue trying to run a RAM image on the Atmel ARM7
> (AT91SAM7SE)  based cpu, in my case the problem was caused because the
> SRAM-Flash remap code that wasn't in the RAM image startup sequence.
>
> Tom
>
> On Jan 25, 2008 11:06 PM, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
>   
>> On Fri, Jan 25, 2008 at 01:55:06PM -0800, Jean-David Vuillemain wrote:
>>     
>>> Yes i use a mixture of tool in fact...
>>>
>>> "Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?"
>>> Could you be more explicit please.
>>>       
>> I wonder, will you get a hang on a startup stage when you'll build eCos
>> with GNU toolchain from public FTP (a.k.a eCosCentric tools)? And what
>> about behaviors of built application for ROM startup? Does that hang
>> too?
>>
>> Sergei
>>
>>
>>     
>>> JD
>>> 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
>>>       
>>>> On Fri, Jan 25, 2008 at 10:21:39AM -0800, Jean-David Vuillemain wrote:
>>>>         
>>>>> I can run my application with GDB but the breakpoints you point out
>>>>> are not reachable. The program goes straight to the data abort at
>>>>> 0x00000010 after a few instructions.
>>>>> I didn't get any assertion message.
>>>>>           
>>>> I have another question, Is it possible that you use a mixture of tools?
>>>> Is your GNU toolchain a home-cooked stuff? Does the error occur with
>>>> GCC-3.2.1? If you build eCos with a recent tolchain, it could be that
>>>> you did modify CYGBLD_GLOBAL_CFLAGS and your startup become a broken...
>>>> Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?
>>>>
>>>> Sergei
>>>>
>>>>         
>>>>> 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
>>>>>           
>>>>>> On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
>>>>>>             
>>>>>>> hi,
>>>>>>>
>>>>>>> i have been working with ecos for a couple of months now. I had no
>>>>>>> problem at all with a 8 months old repository source files and my own
>>>>>>> port for my target board. After some problem with my working
>>>>>>> environment  and updating the ecos source files, i can't have my old
>>>>>>> work and my new  code running on the board.
>>>>>>>               
>>>>>> Working with lpc2xxx targets I update eCos repository every week.  Did
>>>>>> you try to build eCos with a tracing support? Import 2 lines the below
>>>>>> with ecosconfig and rebuild eCos
>>>>>>
>>>>>> cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
>>>>>> cdl_option CYGDBG_USE_TRACING {user_value 1};
>>>>>>
>>>>>> Can you run your application in GDB as
>>>>>>
>>>>>> b cyg_start
>>>>>> b cyg_assert_fail
>>>>>> c
>>>>>> c
>>>>>>
>>>>>> I wonder, Did you get same assertion?
>>>>>>
>>>>>> ASSERT FAIL: <1>lpc2xxx_misc.c[359]hal_interrupt_configure() Invalid vector
>>>>>>
>>>>>>
>>>>>> Sergei
>>>>>>
>>>>>>             
>>>>>>> It seems that my code always go through the same steps and finishes by
>>>>>>>  an exception abort data.
>>>>>>>
>>>>>>> Here is the code where it fails:
>>>>>>> 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
>>>>>>> 0x80020074 <start+4>:  ldr r1, [r0]
>>>>>>> 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
>>>>>>> 0x8002007c <start+12>: bne 0x80020078 <start+8>
>>>>>>> 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
>>>>>>> 0x80020084 <start+20>: str r1, [r0]
>>>>>>> 0x80020088 <start+24>: mov r0, #0    ; 0x0
>>>>>>> 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
>>>>>>> <.__exception_handlers>
>>>>>>> 0x80020090 <start+32>: cmp r7, #19    ; 0x13
>>>>>>> 0x80020094 <start+36>: beq 0x800200a0 <start+48>
>>>>>>> 0x80020098 <start+40>: ldr r2, [r1, #40]
>>>>>>> 0x8002009c <start+44>: str r2, [r0, #40]
>>>>>>> 0x800200a0 <start+48>: ldr r2, [r1, #24]
>>>>>>> 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
>>>>>>> old and new programs
>>>>>>> It ends up in an abort data:
>>>>>>> 0x00000010 swp             r1, r3, [r2]
>>>>>>>
>>>>>>> Someone has a hint to solve this problem??
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Jean-David
>>>>>>>
>>>>>>> --
>>>>>>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>>>>>>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>>>>>>               
>>>>> --
>>>>> Jean-David Vuillemain
>>>>> jdvuillemain@gmail.com
>>>>>           
>>> --
>>> Jean-David Vuillemain
>>> jdvuillemain@gmail.com
>>>       
>> --
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>>
>>     
>
>   



----------------------------------------------------------------------
Sprawdz, czy pasujesz do swojego partnera!
http://link.interia.pl/f1ce7


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] arm7 lpc2xxx abort data exception

[Jean-David Vuillemain]

Thanks for all the answers and hints. None of them so far helped me.
That is why I have a simple question:
If I compile the GDB stubs of the phycore2294 (in ecoscentric
repository tree) and that I download it on my board (with a lpc2294)
with the philips flash utility, I should see something out of the
diagnostic channel on power up?
I understand that my board is not exactly the same as the phycore2294,
but the GDB stub is doing very minimal initialization. I am using the
configtool from eCoscentric, the arm-elf toolchain from ecos webiste
and philips flash utility to download the code on the target board.

greetings
JD


2008/1/25, Jean-David Vuillemain <jdvuillemain@gmail.com>:
> ROM startup is hanged to. THe same behaviour for all my tests.
>
> I used the configtool form eCoscentric with the GNU tool chain from
> ecos this is gcc3.2.1 (I followed the instructions on ecos website).
> I create a GDB stub with an existing port for lpc2294 and it hangs at
> the same place.
>
> 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > On Fri, Jan 25, 2008 at 01:55:06PM -0800, Jean-David Vuillemain wrote:
> > > Yes i use a mixture of tool in fact...
> > >
> > > "Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?"
> > > Could you be more explicit please.
> >
> > I wonder, will you get a hang on a startup stage when you'll build eCos
> > with GNU toolchain from public FTP (a.k.a eCosCentric tools)? And what
> > about behaviors of built application for ROM startup? Does that hang
> > too?
> >
> > Sergei
> >
> > > JD
> > > 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > > > On Fri, Jan 25, 2008 at 10:21:39AM -0800, Jean-David Vuillemain wrote:
> > > > > I can run my application with GDB but the breakpoints you point out
> > > > > are not reachable. The program goes straight to the data abort at
> > > > > 0x00000010 after a few instructions.
> > > > > I didn't get any assertion message.
> > > >
> > > > I have another question, Is it possible that you use a mixture of tools?
> > > > Is your GNU toolchain a home-cooked stuff? Does the error occur with
> > > > GCC-3.2.1? If you build eCos with a recent tolchain, it could be that
> > > > you did modify CYGBLD_GLOBAL_CFLAGS and your startup become a broken...
> > > > Can you undo for GCC-3.2.1 and rebuild new CVS eCos with original tools?
> > > >
> > > > Sergei
> > > >
> > > > > 2008/1/25, Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> > > > > > On Thu, Jan 24, 2008 at 03:38:14PM -0800, Jean-David Vuillemain wrote:
> > > > > > > hi,
> > > > > > >
> > > > > > > i have been working with ecos for a couple of months now. I had no
> > > > > > > problem at all with a 8 months old repository source files and my own
> > > > > > > port for my target board. After some problem with my working
> > > > > > > environment  and updating the ecos source files, i can't have my old
> > > > > > > work and my new  code running on the board.
> > > > > >
> > > > > > Working with lpc2xxx targets I update eCos repository every week.  Did
> > > > > > you try to build eCos with a tracing support? Import 2 lines the below
> > > > > > with ecosconfig and rebuild eCos
> > > > > >
> > > > > > cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
> > > > > > cdl_option CYGDBG_USE_TRACING {user_value 1};
> > > > > >
> > > > > > Can you run your application in GDB as
> > > > > >
> > > > > > b cyg_start
> > > > > > b cyg_assert_fail
> > > > > > c
> > > > > > c
> > > > > >
> > > > > > I wonder, Did you get same assertion?
> > > > > >
> > > > > > ASSERT FAIL: <1>lpc2xxx_misc.c[359]hal_interrupt_configure() Invalid vector
> > > > > >
> > > > > >
> > > > > > Sergei
> > > > > >
> > > > > > > It seems that my code always go through the same steps and finishes by
> > > > > > >  an exception abort data.
> > > > > > >
> > > > > > > Here is the code where it fails:
> > > > > > > 0x80020070 <start>:    ldr r0, [pc, #1020]    ; 0x80020474 <.init_flag>
> > > > > > > 0x80020074 <start+4>:  ldr r1, [r0]
> > > > > > > 0x80020078 <start+8>:  cmp r1, #0    ; 0x0
> > > > > > > 0x8002007c <start+12>: bne 0x80020078 <start+8>
> > > > > > > 0x80020080 <start+16>: ldr r1, [pc, #196]    ; 0x8002014c <init_done>
> > > > > > > 0x80020084 <start+20>: str r1, [r0]
> > > > > > > 0x80020088 <start+24>: mov r0, #0    ; 0x0
> > > > > > > 0x8002008c <start+28>: ldr r1, [pc, #988]    ; 0x80020470
> > > > > > > <.__exception_handlers>
> > > > > > > 0x80020090 <start+32>: cmp r7, #19    ; 0x13
> > > > > > > 0x80020094 <start+36>: beq 0x800200a0 <start+48>
> > > > > > > 0x80020098 <start+40>: ldr r2, [r1, #40]
> > > > > > > 0x8002009c <start+44>: str r2, [r0, #40]
> > > > > > > 0x800200a0 <start+48>: ldr r2, [r1, #24]
> > > > > > > 0x800200a4 <start+52>: str r2, [r0, #24]    <-- this line fails on my
> > > > > > > old and new programs
> > > > > > > It ends up in an abort data:
> > > > > > > 0x00000010 swp             r1, r3, [r2]
> > > > > > >
> > > > > > > Someone has a hint to solve this problem??
> > > > > > >
> > > > > > > Thanks in advance.
> > > > > > >
> > > > > > > Jean-David
> > > > > > >
> > > > > > > --
> > > > > > > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > > > > > > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jean-David Vuillemain
> > > > > jdvuillemain@gmail.com
> > > >
> > >
> > >
> > > --
> > > Jean-David Vuillemain
> > > jdvuillemain@gmail.com
> >
>
>
> --
> Jean-David Vuillemain
> jdvuillemain@gmail.com
>


-- 
Jean-David Vuillemain
jdvuillemain@gmail.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss