public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: John Dallaway <john@dallaway.org.uk>
To: schuster_bernd@gmx.net
Cc: eCos Discussion <ecos-discuss@ecos.sourceware.org>
Subject: [ECOS] Re: GDB stub support
Date: Mon, 17 Dec 2012 19:01:00 -0000	[thread overview]
Message-ID: <50CF6BE2.1020305@dallaway.org.uk> (raw)
In-Reply-To: <20121217172456.214150@gmx.net>

Hi Bernd

On 17/12/12 17:24, Bernd Schuster wrote:

> unfortunately I couldn`t get GDB working as expected. 
> 
> At the moment, I`m able to run Redboot at my target system - mips32
> 24kc processor as ROMRAM version. When redboot starts, I`m able to
> see all messages from the redboot bootloader by my serial port ttyS0
> (configurated with 115200 baud). After that redboot starts my
> application which is located at the addr 0x800400BC by a short boot
> script. 
> 
> Now, I`m trying to add GDB support by using the same serial interface
> ttyS0. I`m not totally sure if that could be already the problem,
> because my application also puts some messages to this serial interface. 
> 
> When I enable GDB with the following commands I can see that cutecom -
> terminal programm - will go from the open to the close state. That`s
> seems a correct behaviour to me. Furthermore I got a very small message
> on the serial terminal - something like that: 
> 
> RedBoot> 
> RedBoot>+$#00

You have two host-side applications competing for incoming characters
arriving on a single serial port. In the above example, your terminal
emulator has received characters intended for GDB. You must close your
terminal program before attempting to connect to RedBoot's GDB stub.

It is perfectly feasible to use a single channel for both debug and
diagnostics as you suggest. You should configure eCos (for your
application build) with CYG_HAL_STARTUP == "RAM" and with
CYGSEM_HAL_USE_ROM_MONITOR enabled. You should then find that (by
default) diagnostic/trace messages from your application are routed via
the GDB stub and appear within your GDB session on the host.

For avoidance of doubt, you can use the GDB "load" command to download
your application to RAM when debugging an application configured for RAM
startup. It is not necessary to load it at the "RedBoot>" prompt.

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2012-12-17 19:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-17 17:25 [ECOS] " Bernd Schuster
2012-12-17 19:01 ` John Dallaway [this message]
2012-12-17 21:04   ` [ECOS] " Bernd Schuster
2012-12-18  8:39     ` Bernd Schuster
2012-12-18  8:45       ` Bernd Schuster
2012-12-18 10:28     ` John Dallaway
2012-12-18 11:56       ` Bernd Schuster
2012-12-18 12:09       ` Bernd Schuster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50CF6BE2.1020305@dallaway.org.uk \
    --to=john@dallaway.org.uk \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=schuster_bernd@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).