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::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::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