[ECOS] ATMEL eb55 Redboot_RAM problem !

[Pete Barrie]

At 10:43 29/10/2002 +0100, Laurent Gonzalez wrote:
>Hi denis,
>
> > Compiling was OK but in order to be able to run, I had to modified the
> > linker .ldi file to avoid to overwrite Angel while it was downloading. I
> > configured my RedBoot_RAM elf file for downloading at address 0x2000000 and
> > execution at 0x2000040. And downloading was OK. I ran  RedBoot_RAM as
> > specified in documentation, but I can not get the RedBoot> prompt.
> >
> > After investigation using various methods (using Angel stub, or set leds
> > on/off), I found the problem resides in the macro CYGACC_CALL_IF_DELAY_US
> > called from main.c.
>It makes sense. When invoking CYGACC_CALL_IF_DELAY_US, you will call a 
>virtual
>vector. In other words Redboot initializes a pointer table with the entry
>points of various useful routines.
>This is the design of eCos: redboot behave as a ROM monitor and provide
>service for debugging applications.
>In your case it sounds like this table is not initialized.
>
> >
> > That macro resulting assembler code from the compiled and linked 
> RedBoot_RAM
> > file is simple and consists in fetching from memory the address of a 
> routine
> > and pass a value which I supposed to be a delay. Unfortunately, the fetched
> > routine address (0x2000048) is bullshit and when the PC is set to that
> > value, an exception is generated.
>My guess is that your redboot is generated with CYG_HAL_STARTUP == RAM, then
>as it is not ROM, it is not a ROM monitor and does not install the virtual
>vector table properly (see CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE and the
>followings in your ecc file)
>
>
> > But the GDB stub is running and I can connect to the target with serial
> > settings  that are different from angel's (38400 instead of 9600).
> >
> > I tried to investigate how the few assembler lines of code correcponding to
> > that macro were generated and arrived in the file
> > ../hal/common/current/include/hal_if.h
> >
> > Here I found the macro code but it is very confusing.
> >
> > Did somebody already encounter that problem ??? Anyway, I will appreciate
> > any hints or advice.
> >
> > There is also one thing that is not clear in my head : I am running a
> > program (RedBoot_RAM) with a stub (Angel or GDB) that allow some debugging.
> > Basically, debugging in RAM consists in replacing an instruction with an
> > interrupt that will activate the debugger. The interrupt was placed at
> > proper place by the debugger.
> > Here is what bother me : on one side we have a debugger that is tied to a
> > software interrupt, and on the other side we have a RedBoot_RAM code that
> > will dialog through a serial communication with a host computer running 
> GDB,
> > and using serial port forced to use interrupts also..
> > Is it safe ??? I suppose that the RedBoot_RAM uses the GDB stub to
> > communicate with the host, am I right ??? Should I build my RedBoot_RAM
> > without the GDB stub ???
>You're right, Angel and GDBstubs does not use the same interrupting process
>(angel uses SWI and GDBstubs use illegal instruction), but both are 
>running on
>the targeted board and are remotely controlled with GDB through a dedicated
>protocol using a serial line.
>You only need angel to load code into the target ram (in our case a ram
>version of redboot) and to launch it. Then you stop angel connection with ^Z
>and redboot is the only piece of software that is running on your board,
>connect to it and enjoy!
>
>My advice for building a temporary redboot and bootstrap an eb55:
>configure redboot with CYG_HAL_STARTUP==RAM and CYGSEM_HAL_ROM_MONITOR==1.
>This will generate an error that you can ignore, then you build redboot that
>will execute in RAM from address 0x2000000.
>Remember that this redboot is only useful to bootstrap your eb55, you need to
>build a ROM version of redboot and flash it on the board.
>
>
> >
> > Thank you for your attention and answers.
> > Denis
> >
>
>PS: Our company has acquired a strong experience on atmel boards running 
>eCos, and we successfully run eCos on eb55 for more than one year.

Is there a working publicly available EB55 port? I am looking for this for 
educational use
in a University teaching lab.

Pete



>GONZALEZ Laurent
>Silicomp Research Institute
>Tel: 04 76 63 48 63
>
>
>
>--
>Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
>and search the list archive: http://sources.redhat.com/ml/ecos-discuss


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