This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Jeeni + Ep7211 ( works now !!!)
- To: grante at visi dot com
- Subject: Re: Jeeni + Ep7211 ( works now !!!)
- From: "danish iftikhar" <d_iftikhar at hotmail dot com>
- Date: Tue, 16 Jan 2001 10:36:53 -0000
- Cc: gdb at sourceware dot cygnus dot com
Hi all
I am able to download and run my application to the EP7211 board through
Jeeni .
Actually where i was getting stucked in was <cyg_hal_invoke_constructors>
. The problem was with i/o initialisation . The eCos start up code checks
for the UArt port to initialise it . In my case since Jeeni was connected
through the JTAG , there was basically nothing on UART1 of EP7211 where eCos
code was waiting .
So what i did was that , besides connecting through JTAG i just connected
the Uart 1 of EP7211 board to the COM port of my PC . I found that it got
hanged after sending some data on the port which shows that probably it was
waiting for something to respond . Then i just start sending "+" ( i don't
know why ?) from my PC to the board through UART1 and it came out of the
loop and started working properly .
Hope it can help some of you .
regards
danish.
>
>
>On Mon, Jan 15, 2001 at 08:36:53AM -0000, danish iftikhar wrote:
>
> > I am trying to use Jeeni to debug my application .
> > I downloaded the code to the EP7211 target board . But the program is
>not
> > able to come upto main() even . Doing "stepi" ( as "step" causes it to
>hang)
> > i found that it goes till "cyg_hal_invoke_constructors" and hangs inside
> > that .
>
>There is no symbol info present in the vector.S file (where the
>entry point is for eCos apps). That means that "step" and
>"next" don't know where the next line is.
>
> > I am attching the rdi.log file produced when i tried to "continue" the
>code
> > . can any of you make out from this what's happenning .
> > The log file was enabled after downloading the code : so it shows the
>last
> > couple of transactions happened between the two guys :
> > ADP log file opened at Mon Jan 15 19:02:40 2001
> >
> > tx: [T=0 L=25] 01 5e 5d 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff
>ff ff 00 20 00 00
> > R=00010005 H->T CI_HADP: ADP_CPUread ff 00002000
> > rx: [T=0 L=28] 01 5e 5e 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff
>ff 00 00 00 00 54 18 00 00
> > R=80010005 H<-T CI_HADP: ADP_CPUread 00000000 00001854
> > tx: [T=0 L=29] 01 5f 5e 01 09 00 01 00 00 00 00 00 ff ff ff ff ff ff ff
>ff 44 85 00 00 00 00 00 00 00
> > R=00010009 H->T CI_HADP: ADP_SetBreak 00008544 00000000 00000000
> > rx: [T=0 L=36] 01 5f 5f 01 09 00 01 80 00 00 00 00 ff ff ff ff ff ff ff
>ff 00 00 00 00 78 ec 03 00 74 fe 1e 00 dc 98 00 00
> > R=80010009 H<-T CI_HADP: ADP_SetBreak 00000000 0003ec78 001efe74
>000098dc
> > tx: [T=0 L=24] 01 60 5f 01 0d 00 01 00 00 00 00 00 ff ff ff ff ff ff ff
>ff 00 00 00 00
> > R=0001000d H->T CI_HADP: ADP_Execute 00000000
> > rx: [T=0 L=24] 01 60 60 01 0d 00 01 80 00 00 00 00 ff ff ff ff ff ff ff
>ff 00 00 00 00
> > R=8001000d H<-T CI_HADP: ADP_Execute 00000000
> >
> >
> > Nothing comes after this .
> >
> > whats wrong here ??
>
>Something is happening in cyg_hal_invoke_constructors() that is
>messing up your target hardware -- in my experience this
>symptom is usually caused by a hardware reset. The stuff
>called by cyg_hal_invoke_constructors() is in C/C++ and should
>include debug info, so step/next/finish should work. You need
>to step through all of the init routines called by
>cyg_hal_invoke_constructors() and figure out what is causing
>your hardware to lock up.
>
>--
>Grant Edwards
>grante@visi.com
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.