Re: [ECOS] GDB "invalid remote reply"...

[Jonathan Larmour <jifl at eCosCentric dot 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