This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: GDB "invalid remote reply"...
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: "Schumacher, Gordon" <gordon_schumacher at maxtor dot com>
- Cc: "'ecos-discuss at sources dot redhat dot com'" <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 05 Nov 2002 18:22:36 +0000
- Subject: Re: [ECOS] GDB "invalid remote reply"...
- References: <E836CBDA0DC0D5118606009027DE2A0C983C2A@mcoexc02.mlm.maxtor.com>
Schumacher, Gordon wrote:
# -----Original Message-----
# From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
# Sent: Monday, November 04, 2002 7:55 PM
# To: Schumacher, Gordon
# Cc: 'ecos-discuss@sources.redhat.com'
# Subject: Re: [ECOS] GDB "invalid remote reply"...
#
# Looks like your UART is spitting out double characters.
# If you use the GDB console you can try using "set debug remote 1"
# and then definitely seeing what gets sent and received.
I've had "debug remote" turned on, and I've tried viewing with just a
terminal program. I was definitely seeing the doubled "00ttrraa" on the
port. The question is, *why*? The doubled characters don't follow the
hardware - that is, I've got the "debug the I/O subsystem" switch turned on,
so that I see a dump of the ports being initialized to the port that's not
connected to GDB... and those characters aren't doubled, no matter which
port they're on.
The "debug the I/O subsystem" stuff is still at a higher level than the
hardware driver. I would say add your own debug stuff in the hardware
driver. Obviously it would be even clearer if you have a serial analyzer.
And perhaps check a disassembly of the UART write operation in case some
compiler glitch (or absence of some important "volatile") is causing it to
store twice to the same address.
# Instead look at the address. When connecting to a RedBoot
# running in ROM it should be a ROM address.
Well, I'm not running RedBoot, because of the configuration of our hardware.
We have 1MB of ROM, but only 128KB of RAM. So, I'm trying to run as much
out of ROM as possible.
The address matches in the MAP file...
Oh, built-in stub then. That does seem odd then.
Okay, here's a slightly different, but related, question. Apparently,
trying to open and write to "/dev/ttydiag" is what was causing it to jump
into the weeds. If I don't do that, though... I can't connect with GDB at
all - the only data I get from the GDB port is a single + character at
startup (which in the code is documented as "ackt outstanding packets"). I
never see more GDB packets.
The target with a built-in stub won't be listening for GDB so when GDB
tries to connect it won't reply. It will only listen for a ctrl-c (0x3).
To force it to stop and listen for GDB, insert a call to breakpoint() at
the point you want to start debugging your program.
Because my initial cyg_io_write() fails, my code goes into an infinite debug
loop (blink LEDs), with calls to cyg_thread_yield() inside of it. I'd have
thought that would be sufficient to let GDB operate - but apparently I'm
incorrect.
GDB stuff doesn't operate in a background thread. The only thing there is
is an interrupt handler on the serial device that will check for ctrl-c.
Jifl
--
eCosCentric http://www.eCosCentric.com/ <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss