Can't connect to remote target in a confused state

Can't connect to remote target in a confused state

[Shaun Jackman]

Occasionally my target (arm-elf) may lose its brain due to a program error, 
or what have you. Regardless, I'd still like to be able to attach to it 
with gdb. I use a JTAG device (BDI2000) and as long as the ARM core isn't 
frozen I should be able to attach. This is the error I'm getting...

(gdb) target remote bdi:2001
Couldn't establish connection to remote target
Cannot access memory at address 0xeafffff4

Now, I assume when I attach gdb is trying to figure out what frame/stack etc 
it's in. So one of the frame pointer, or stack pointer, or program counter is 
sitting at 0xeafffff4 and gdb is trying to read the memory there. When it 
can't, it fails. Unfortunately, when this happens I have to power-cycle my 
target and restart gdb to be able to get back to debugging.

Is my analysis correct? Is there some way I can get gdb to attach to the 
target even if it has been left in a "confused" state? My next actions are 
likely going to be to "load" and "run" anyways, so I really don't care that 
it's confused at the moment.

Thanks,
Shaun

Re: Can't connect to remote target in a confused state

[Shaun Jackman]

I forgot to mention I'm using gdb 5.1 on an i686 host.

Cheers,
Shaun

On December 19, 2001 09:58, Shaun Jackman wrote:
> Occasionally my target (arm-elf) may lose its brain due to a program error,
> or what have you. Regardless, I'd still like to be able to attach to it
> with gdb. I use a JTAG device (BDI2000) and as long as the ARM core isn't
> frozen I should be able to attach. This is the error I'm getting...
>
> (gdb) target remote bdi:2001
> Couldn't establish connection to remote target
> Cannot access memory at address 0xeafffff4
>
> Now, I assume when I attach gdb is trying to figure out what frame/stack
> etc it's in. So one of the frame pointer, or stack pointer, or program
> counter is sitting at 0xeafffff4 and gdb is trying to read the memory
> there. When it can't, it fails. Unfortunately, when this happens I have to
> power-cycle my target and restart gdb to be able to get back to debugging.
>
> Is my analysis correct? Is there some way I can get gdb to attach to the
> target even if it has been left in a "confused" state? My next actions are
> likely going to be to "load" and "run" anyways, so I really don't care that
> it's confused at the moment.
>
> Thanks,
> Shaun

Re: Can't connect to remote target in a confused state

[Fernando Nasser]

Shaun,

This is a known problem.

Please see the thread:

http://sources.redhat.com/ml/gdb-patches/2001-11/msg00396.html

Fernando


Shaun Jackman wrote:
> 
> Occasionally my target (arm-elf) may lose its brain due to a program error,
> or what have you. Regardless, I'd still like to be able to attach to it
> with gdb. I use a JTAG device (BDI2000) and as long as the ARM core isn't
> frozen I should be able to attach. This is the error I'm getting...
> 
> (gdb) target remote bdi:2001
> Couldn't establish connection to remote target
> Cannot access memory at address 0xeafffff4
> 
> Now, I assume when I attach gdb is trying to figure out what frame/stack etc
> it's in. So one of the frame pointer, or stack pointer, or program counter is
> sitting at 0xeafffff4 and gdb is trying to read the memory there. When it
> can't, it fails. Unfortunately, when this happens I have to power-cycle my
> target and restart gdb to be able to get back to debugging.
> 
> Is my analysis correct? Is there some way I can get gdb to attach to the
> target even if it has been left in a "confused" state? My next actions are
> likely going to be to "load" and "run" anyways, so I really don't care that
> it's confused at the moment.
> 
> Thanks,
> Shaun

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Can't connect to remote target in a confused state

[Shaun Jackman]

Alright, glad to hear I wasn't far from the mark. What's the status of the 
patch Elena Zannoni submitted? Has any portion of it been included in the 5.1 
tree? Should it apply cleanly to a 5.1 tree? If it hasn't been included yet, 
is there plans to include it in 5.1.1?

Thanks,
Shaun

On December 19, 2001 11:42, Fernando Nasser wrote:
> Shaun,
>
> This is a known problem.
>
> Please see the thread:
>
> http://sources.redhat.com/ml/gdb-patches/2001-11/msg00396.html
>
> Fernando
>
> Shaun Jackman wrote:
> > Occasionally my target (arm-elf) may lose its brain due to a program
> > error, or what have you. Regardless, I'd still like to be able to attach
> > to it with gdb. I use a JTAG device (BDI2000) and as long as the ARM core
> > isn't frozen I should be able to attach. This is the error I'm getting...
> >
> > (gdb) target remote bdi:2001
> > Couldn't establish connection to remote target
> > Cannot access memory at address 0xeafffff4
> >
> > Now, I assume when I attach gdb is trying to figure out what frame/stack
> > etc it's in. So one of the frame pointer, or stack pointer, or program
> > counter is sitting at 0xeafffff4 and gdb is trying to read the memory
> > there. When it can't, it fails. Unfortunately, when this happens I have
> > to power-cycle my target and restart gdb to be able to get back to
> > debugging.
> >
> > Is my analysis correct? Is there some way I can get gdb to attach to the
> > target even if it has been left in a "confused" state? My next actions
> > are likely going to be to "load" and "run" anyways, so I really don't
> > care that it's confused at the moment.
> >
> > Thanks,
> > Shaun

Re: Can't connect to remote target in a confused state

[Elena Zannoni]

Shaun, this is a known problem with arm. I submitted a patch some time
back, and haven't committed it yet. Some minor cleanup is needed.
Try it anyway and see if it works for you:
http://sources.redhat.com/ml/gdb-patches/2001-11/msg00396.html

Elena


Shaun Jackman writes:
 > Occasionally my target (arm-elf) may lose its brain due to a program error, 
 > or what have you. Regardless, I'd still like to be able to attach to it 
 > with gdb. I use a JTAG device (BDI2000) and as long as the ARM core isn't 
 > frozen I should be able to attach. This is the error I'm getting...
 > 
 > (gdb) target remote bdi:2001
 > Couldn't establish connection to remote target
 > Cannot access memory at address 0xeafffff4
 > 
 > Now, I assume when I attach gdb is trying to figure out what frame/stack etc 
 > it's in. So one of the frame pointer, or stack pointer, or program counter is 
 > sitting at 0xeafffff4 and gdb is trying to read the memory there. When it 
 > can't, it fails. Unfortunately, when this happens I have to power-cycle my 
 > target and restart gdb to be able to get back to debugging.
 > 
 > Is my analysis correct? Is there some way I can get gdb to attach to the 
 > target even if it has been left in a "confused" state? My next actions are 
 > likely going to be to "load" and "run" anyways, so I really don't care that 
 > it's confused at the moment.
 > 
 > Thanks,
 > Shaun

Re: Can't connect to remote target in a confused state

[Elena Zannoni]

Shaun Jackman writes:
 > Alright, glad to hear I wasn't far from the mark. What's the status of the 
 > patch Elena Zannoni submitted? Has any portion of it been included in the 5.1 
 > tree? Should it apply cleanly to a 5.1 tree? If it hasn't been included yet, 
 > is there plans to include it in 5.1.1?


Hmmm, 5.1? Don't know. I haven't committed it yet. I needed to pick some 
better names for the functions, then I got sidetracked. I should do that
shortly.

Sorry about that.

Elena

 > 
 > Thanks,
 > Shaun
 > 
 > On December 19, 2001 11:42, Fernando Nasser wrote:
 > > Shaun,
 > >
 > > This is a known problem.
 > >
 > > Please see the thread:
 > >
 > > http://sources.redhat.com/ml/gdb-patches/2001-11/msg00396.html
 > >
 > > Fernando
 > >
 > > Shaun Jackman wrote:
 > > > Occasionally my target (arm-elf) may lose its brain due to a program
 > > > error, or what have you. Regardless, I'd still like to be able to attach
 > > > to it with gdb. I use a JTAG device (BDI2000) and as long as the ARM core
 > > > isn't frozen I should be able to attach. This is the error I'm getting...
 > > >
 > > > (gdb) target remote bdi:2001
 > > > Couldn't establish connection to remote target
 > > > Cannot access memory at address 0xeafffff4
 > > >
 > > > Now, I assume when I attach gdb is trying to figure out what frame/stack
 > > > etc it's in. So one of the frame pointer, or stack pointer, or program
 > > > counter is sitting at 0xeafffff4 and gdb is trying to read the memory
 > > > there. When it can't, it fails. Unfortunately, when this happens I have
 > > > to power-cycle my target and restart gdb to be able to get back to
 > > > debugging.
 > > >
 > > > Is my analysis correct? Is there some way I can get gdb to attach to the
 > > > target even if it has been left in a "confused" state? My next actions
 > > > are likely going to be to "load" and "run" anyways, so I really don't
 > > > care that it's confused at the moment.
 > > >
 > > > Thanks,
 > > > Shaun