[ECOS] arm7 lpc2xxx abort data exception

Gary Thomas gary@mlbassoc.com
Fri Jan 25 21:11:00 GMT 2008


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



More information about the Ecos-discuss mailing list