This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: 4373board stubrom problem
- To: pyxue <root at t2-design dot com>
- Subject: Re: [ECOS] 4373board stubrom problem
- From: Jonathan Larmour <jlarmour at redhat dot co dot uk>
- Date: Wed, 19 Apr 2000 17:02:22 +0100
- CC: ecos-discuss at sourceware dot cygnus dot com
- Organization: Red Hat UK Ltd.
- References: <Pine.LNX.4.10.10004191948410.660-100000@pyxue>
pyxue wrote:
>
> Hi, I have sucessfully built the toolchain and tests for mips4300, but now
> I meet a problem, I can download the tests to the 4373board, but I can't
> get the correct result. Following is the information I get .
>
> bash-2.02$ mips64vr4300-elf-gdb -nw thread_gdb.exe
> .........( the messages of gdb)
> (gdb) set remotebaud 38400
> (gdb) set mips-force-32bit-saved-gpregs
> (gdb) set heuristic-fence-post 0x00005000
> (gdb) target remote com1
> Remote debugging using com1
> 0xbfc04550 in ?? ()
> (gdb) load
> ..................(load the test well)
> (gdb)c
> Continuing.
>
> But the test seems stop, and doesn't give any result, after a while, I
> reset the target, I get the following message:
>
> Program received signal SIGTRAP, trace/breakpoint trap
> 0xbfc04550 in ?? ()
>
> I didn't know why the program stops at the address 0xbfc04550, maybe
> something is wrong with the gdb stubrom, but I try several stubroms with
> different configurations, and get the same result. I use the EPROM
> M27c4001-12F1, and the Rom address is 0xbfc00000, ram address is
> 0x80000100. When I try to set the ram address to 0xa0000100, and the same
> problem remains. Can someone do me a favor to solve the problem, Thanks a
> lot!
It seems like the gdb stubrom is working from the information you've given.
However we have had problems with the recent gcc snapshots. Try setting GDB
breakpoints at early stages in the startup and see if it gets that far. Try
"break cyg_hal_invoke_constructors" for example. See if you can debug this
one out, but be aware that it may be a compiler problem so looking at the
assembler is more important than the C code.
Jifl
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault