[ECOS] Problems with CEB-v850/SA1

[ECOS] Problems with CEB-v850/SA1

[Wolfram Kattanek]

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

Re: [ECOS] Problems with CEB-v850/SA1

[Jonathan Larmour]

[-- Attachment #1: Type: text/plain, Size: 6183 bytes --]

Wolfram Kattanek wrote:
> 
> 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.

Don't worry about the odd addresses to do with memory allocators - it's
just because GDB is trying (and failing) to find the source associated with
the breakpoint in ROM. Since you are debugging a RAM program, not the stub
ROM, that's not surprising!

As for your other problem, I have fixed that in local sources as it
happens, but haven't checked it in yet. I've attached a known good GDB stub
ROM. Use v850-elf-objcopy to copy it from ELF to other formats for
programming (bin, srec).

You will also need to make sure the attached v850.hex file is programmed
into your chip internal flash. It may already be... I confess I'm not clear
on what the V850s on Cosmo boards ships with.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine
gdb_module.img
S32500000000070A400F4CF0010A400F64F08F07F4FF9007000000000000000000000000000070
S32500000020BC070000000000000000000000000000BC07000000000000000000000000000034
S32500000040BC070000000000000000000000000000BC07000000000000000000000000000014
S32500000060BC070000000000000000000000000000BC070000000000000000000000000000F4
S32500000080BC070000000000000000000000000000BC070000000000000000000000000000D4
S325000000A0BC070000000000000000000000000000BC070000000000000000000000000000B4
S325000000C0BC070000000000000000000000000000BC07000000000000000000000000000094
S325000000E0BC070000000000000000000000000000BC07000000000000000000000000000074
S32500000100BC070000000000000000000000000000BC07000000000000000000000000000053
S32500000120BC070000000000000000000000000000BC07000000000000000000000000000033
S32500000140BC070000000000000000000000000000BC07000000000000000000000000000013
S32500000160BC070000000000000000000000000000BC070000000000000000000000000000F3
S32500000180BC070000000000000000000000000000BC070000000000000000000000000000D3
S325000001A0BC070000000000000000000000000000BC070000000000000000000000000000B3
S325000001C0BC070000000000000000000000000000BC07000000000000000000000000000093
S325000001E0BC070000000000000000000000000000BC07000000000000000000000000000073
S32500000200BC070000000000000000000000000000BC07000000000000000000000000000052
S32500000220BC070000000000000000000000000000BC07000000000000000000000000000032
S32500000240BC070000000000000000000000000000BC07000000000000000000000000000012
S32500000260BC070000000000000000000000000000BC070000000000000000000000000000F2
S32500000280BC070000000000000000000000000000BC070000000000000000000000000000D2
S325000002A0BC070000000000000000000000000000BC070000000000000000000000000000B2
S325000002C0BC070000000000000000000000000000BC07000000000000000000000000000092
S325000002E0BC070000000000000000000000000000BC07000000000000000000000000000072
S32500000300BC070000000000000000000000000000BC07000000000000000000000000000051
S32500000320BC070000000000000000000000000000BC07000000000000000000000000000031
S32500000340BC070000000000000000000000000000BC07000000000000000000000000000011
S32500000360BC070000000000000000000000000000BC070000000000000000000000000000F1
S32500000380BC070000000000000000000000000000BC070000000000000000000000000000D1
S325000003A0BC070000000000000000000000000000BC070000000000000000000000000000B1
S325000003C0BC070000000000000000000000000000BC07000000000000000000000000000091
S325000003E0BC070000000000000000000000000000BC07000000000000000000000000000071
S70500000000FA

[-- Attachment #2: gdb_module.img --]
[-- Type: application/x-executable, Size: 32308 bytes --]

Re: [ECOS] Problems with CEB-v850/SA1

[Wolfram Kattanek]

> As for your other problem, I have fixed that in local sources as it
> happens, but haven't checked it in yet. I've attached a known good GDB stub
> ROM. Use v850-elf-objcopy to copy it from ELF to other formats for
> programming (bin, srec).
> 
> You will also need to make sure the attached v850.hex file is programmed
> into your chip internal flash. It may already be... I confess I'm not clear
> on what the V850s on Cosmo boards ships with.

Thanks for your help! (Nearly) everything works fine now. One of the left
problems deals with breakpoints inside gdb. We can set breakpoints but the
program doesn't stop. If we stop the program with the "stop" button inside
Insight the program stops but hangs if we step through the code after that.
Maybe this problem is related with the (probably missing) v850.hex code
inside the internal flash? What is the function of this code? Because we're
still waiting for a flasher tool for the v850 we couldn't program it yet.

Another question: Are there any other ports for the v850 architecture? There
is another V850 eval board called "startWARE Starterkit" from NEC which we're
interested in. Are there any ongoing (or completed) porting efforts towards
this board?

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

Re: [ECOS] Problems with CEB-v850/SA1

[Wolfram Kattanek]

Jonathan Larmour <jlarmour@redhat.com>:

> As for your other problem, I have fixed that in local sources as it
> happens, but haven't checked it in yet. I've attached a known good GDB stub
> ROM. Use v850-elf-objcopy to copy it from ELF to other formats for
> programming (bin, srec).
> 
> You will also need to make sure the attached v850.hex file is programmed
> into your chip internal flash. It may already be... I confess I'm not clear
> on what the V850s on Cosmo boards ships with.

Jonathan,

not long ago you helped us with our problems regarding the CEB-v850/SA1 board.
You sent a "known good GDB stub" file and mentioned that you eventually will
check in the fixed local sources. Did you do that already? Or can you give us
a hint which sources we have to use to build a "good GDB stub" for our own?
We need a "good" starting point for our porting activities.

What is the function of v850.hex file? Because of some HW problems we couldn't
program it yet. We're trying to port eCos to another V850/SA1 board (startWARE
from NEC) and thats why every information is very welcome! 

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