Hi,
Before anyone points it out, the buffer in the example below isn't
big enough.
Note that for clarity other code has been removed from the original
that this example comes from (e.g. handling other exceptions, checks
for bounds in the array access etc.).
A final point to make is that you clearly have to be careful what
functions you're calling in such a handler, as by definition
something unexpected and bad has happened, and things are probably
not as you expect them (e.g. stack pointer, memory). In particular,
don't try and use interrupts in this mode.
Brendan
--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
>
>
> Data abort exceptions are caused by a signal from the memory system
> (i.e. are specific to the ARM implementation). On the LPC2148, see
> section 2.3 "Prefetch abort and Data Abort exceptions" for when
they
> are signalled (basically, references to invalid memory addresses).
>
> The exception is handled by one of the vectors at the exception
> vector table - see section 2.2.1 of the usear manual.
>
> The processor loads the address of the aborted instruction (+ 8)
into
> r14 (i.e.lr) when it happens.
>
> My guess is that the lr has been overwritten by the time your
> function has been called.
>
> You could try something like:
>
> _int_vectors:
>
> ldr pc, do_reset_addr
> ldr pc, do_undefined_instruction_addr
> ldr pc, do_software_interrupt_addr
> ldr pc, do_prefetch_abort_addr
> ldr pc, do_data_abort_addr
> nop
> ldr pc, do_irq_addr
> ldr pc, do_fiq_addr
>
> /* table of interrupt handler adresses */
>
> do_reset_addr: .long do_reset
> do_undefined_instruction_addr: .long
do_undefined_instruction
> do_software_interrupt_addr: .long do_software_interrupt
> do_prefetch_abort_addr: .long do_prefetch_abort
> do_data_abort_addr: .long do_data_abort
> do_irq_addr: .long do_irq
> do_fiq_addr: .long do_fiq
>
> do_undefined_instruction:
> mov r0, #0
> sub r1, r14, #4
> b exception_handler
>
> do_prefetch_abort:
> mov r0, #1
> sub r1, r14, #4
> b exception_handler
>
> do_data_abort:
> mov r0, #2
> sub r1, r14, #8
> b exception_handler
>
> and then have something like:
>
> /*
> * Handle exceptions
> * Called close to startup with the original cause of the re-start
> */
>
> void exception_handler(int exception_type, int location)
>
> {
> static const char * const exception_name[] =
> {
> "undefined instruction",
> "prefetch abort",
> "data abort"
> };
>
> char buffer[40];
>
> /* print out the cause of the exception */
>
> sprintf(buffer, "\r\nEXCEPTION at 0x%08x (%d): %s\r\n",
> location, exception_type,
> exception_name[exception_type]);
>
> polled_write_to_debug_port(buffer);
>
> while (1)
> {
> ;
> }
>
> return;
> }
>
> This gets rid of any problems with in-line assembler (!).
>
> Hope this helps
>
> Brendan.
>
> --- In lpc2000@yahoogroups.com, "frodri123123" <fer@> wrote:
> >
> > I have some code which is causing a dabort exception. I am
> > using an Embedded Artists board (with lpc 2148) with the gnu
> > debugging environment. I am trying to debug the code through a
> > serial console. Now, when the exception occurs, it gets caught
in
> > the follwing routine:
> >
> > static void
> > exceptionHandlerDabort(void)
> > {
> > register unsigned int programCounter asm ("lr");
> > unsigned int value = programCounter - (unsigned int)
> 0x08;
> >
> > consolSendString("Dabort exception !!!\nAddress: 0x");
> > consolSendNumber(16, 8, 0, '0', value);
> > while(1)
> > ;
> > }
> >
> >
> > An I get:
> >
> > Dabort exception !!!
> > Address: 0x00001E80
> >
> > thrown in the console... However that address corresponds to:
> >
> > $ arm-elf-addr2line -e myproject.elf 1E80
> > ../startup/consol.c:263
> >
> > which is precisely the SendString instruction; so it would seem
to
> > me that value displayed is the current PC, and not the PC where
> the
> > exception occurred...
> >
> >
> > So I guess I am asking:
> >
> > 1- Why is a dabort exception generated? My understanding is that
> > they are caused by invalid memory access; however I am not clear
as
> > to what constitues an invalid memory access for the lpc2148. Is
it
> > unaligned access? or is it access to non existing memory?
> >
> > 2- Is the exception effectively generated at the consol.c file;
or Show quoted textHide quoted text
> > is there some magic to make the exception handling framework work
> > properly?
> >
> > Hope someone can help...
> >
> > ps. I am new to the ARM family; so maybe I am just being thick...
> >
>