This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Can't connect to remote target in a confused state
- From: Fernando Nasser <fnasser at redhat dot com>
- To: Shaun Jackman <sjackman at pathwayconnect dot com>
- Cc: gdb at sources dot redhat dot com, Elena Zannoni <ezannoni at cygnus dot com>
- Date: Wed, 19 Dec 2001 13:42:55 -0500
- Subject: Re: Can't connect to remote target in a confused state
- Organization: Red Hat , Inc. - Toronto
- References: <E16Gk2s-0007Jk-00@dazed>
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