RE: [ECOS] Bug in arm vectors.S ???

[Gary Thomas <gthomas at redhat dot com>]

I'd say the problem is with your LED macro.  Either have it use
other registers, or get rid of it.

At this time, the LED macro is only used during initial board
bringup.  It's reasonable that the code assume that the macro
does not destroy any registers in use.

On 02-Aug-2000 Carl van Schaik wrote:
> Hi
> 
> With refernece to the lines :
> 
>         str     r2,[r0,#0x10]
>         ldr     r2,[r1,#0x30]
>         str     r2,[r0,#0x30]
> 
>         LED 4
> 
>#if defined(CYG_HAL_STARTUP_ROM)
>         // Set up reset vector
>         ldr     r2,[r1,#0x00]    // reset vector intstruction
>         str     r2,[r0,#0x00]
>         ldr     r2,=warm_reset
>         str     r2,[r0,#0x20]
>         // Relocate [copy] data from ROM to RAM
>         ldr     r3,.__rom_data_start
>         ldr     r4,.__ram_data_start
>         ldr     r5,.__ram_data_end
> 
> After the "LED" macro, r0 and r1 may have been corrupted, I know in my
> port and in the pid hal_platform_setup.h the LED routines are using r0 and
> not restoring it. Thus an <abort_prefetch> could occur.
> 
> Am I correct in this assumption? Should the LED code not use r0 and r1?
> Should the code above be modified? by inserting
> "
>         mov     r0,#0           // move vectors
>         ldr     r1,.__exception_handlers
> "
> after the LED 4 macro.
> 
> thanks
> 
> Carl van Schaik   <carl@leg.uct.ac.za>
> -----------------------------------------------------
> Dept. Electrical Engineering, UCT
> 
> 621 Menzies Building
> University of Cape Town
> Rondebosch   
> Western Cape
> 7700
> South Africa
> 
> Tel: +27 21 650-3467
> Fax: +27 21 650-3465
>