Lpc2000

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