[ECOS] Problems with CEB-v850/SA1

[Wolfram Kattanek <wolfram.kattanek@imms.de>]

Hi all,

we're trying to run eCos on a Cosmo CEB-v850/SA1 eval board which is in the list
of "official" supported targets. Unfortunately we've run into several problems:

We built the gdb stub from the latest eCos CVS sources and programmed the boards
EPROM with it (replacing the monitor and diagnosis software in that EPROM). The
stub seems to work correctly. Then we wanted to run the eCos tests.

But when we try to download and run any (eCos) program on the board something is
going wrong. We can download the program binary (download dialog and download progress
messages can be seen) but before that there are strange messages when selecting
the target. Here's an example scenario (we built eCos with "ecosconfig new CEB ;
ecosconfig tree ; make tests"):

>v850-elf-gdb -nw install/tests/kernel/current/tests/thread_gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=v850-elf"...
(gdb) set remotebaud 38400
(gdb) ta re /dev/ttyS0
Remote debugging using /dev/ttyS0
Cyg_Mempolt2<Cyg_Mempool_dlmalloc_Implementation>::free (this=0x0,
    p=0xfc07dc "", size=6)
    at /system_spec/ecos/cvs/repositories/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1571
1571    {
(gdb) load
Loading section .text, size 0x4c9a lma 0xfc4000
Loading section .rodata, size 0x400 lma 0xfc8c9c
Loading section .data, size 0x182c lma 0xfc909c
Start address 0xfc4000 , load size 26822
Transfer rate: 23841 bits/sec, 478 bytes/write.
(gdb) c
Continuing.

And then nothing happens and the program hangs.

Sometimes there are other messages after target selection, for instance:

...
0xfc1e68 in ?? ()
    at /system_spec/ecos/cvs/repositories/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1257
1257      return chunk2mem(victim);
...

or

...
0x6 in Cyg_Mempolt2<Cyg_Mempool_dlmalloc_Implementation>::free (this=0x0,
    p=0xfc07dc "", size=6)
    at /system_spec/ecos/cvs/repositories/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1573
1573                         CYG_MEMPOOL_STAT_TOTALALLOCATED|CYG_MEMPOOL_STAT_MAXFREE)))
...


Is this a stub problem or is it a memory/adress problem with the stub and the program?
We have absolutely no idea where these problems come from. We would be grateful for any
hints regarding the above mentioned problems.

Wolfram
--
Wolfram 'L.A.' Kattanek     Institut fuer Mikroelektronik- und
Email:       LA@imms.de     Mechatronik-Systeme (IMMS) gGmbH     
Tel: +49 3677 / 6783-55     Langewiesener Str. 22
Fax: +49 3677 / 6783-38     98693 Ilmenau / Germany

-------------------------------------------------
This mail sent through IMP: imp.imms.de