This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ATMEL eb55 Redboot_RAM problem !


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.



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]