This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Debugging from ROM
- From: "Gary D. Thomas" <gary dot thomas at mind dot be>
- To: Rich LeGrand <rich at charmedlabs dot com>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 13 Mar 2003 07:05:17 -0700
- Subject: Re: [ECOS] Debugging from ROM
- References: <ALEFICMPOAICDGJBCPJEIEEGCCAA.rich@charmedlabs.com>
On Wed, 2003-03-12 at 22:07, Rich LeGrand wrote:
> Hi all,
> I'm not sure if debugging from ROM is something that has been done very
> often with eCos and gdb -- perhaps targets/processors with hardware
> breakpoints allow this.
>
> But it seems that eCos is geared (at least somewhat) for debugging out of
> RAM with the help of a ROM monitor. Here, a debugging scenario entails
> linking your client code with a RAM-enabled eCos library and loading it into
> RAM through the gdb stub. In general this is a very nice debugging
> facility. But since your target application will typically be running out
> of ROM this poses some limitations, especially if you are RAM-constrained
> and your target app won't fit. And as luck would have it, even if the app
> does fit, bugs don't always behave the same when running out of RAM vs ROM.
>
> A more convenient scenario which offers more freedom would be to have the
> target running out of ROM. And when the developer wants to, he/she can
> attach a debugging cable and break the program and examine what is going on
> through a remote gdb session. After poking around he/she can resume the
> program and unplug the debugging cable to let the system resume doing its
> thing.
>
> Debugging out of ROM requires some kind of special mechanism on the platform
> for setting breakpoints, but lets assume that we have this. If we have the
> gdb stub compiled into our ROM target we should be able to "wake" the stub
> through an interrupt on the communication channel and break the program
> execution. ONe idea to have the diag console outputting raw data until it
> gets a gdb character '$' and then it switches to a gdb-mangler data (sorta
> like RedBoot does) We continue in "gdb mode" until we get a $k#6b packet
> from gdb quitting and then we resume the program (and the console goes back
> into raw mode). Switching console modes could be done by rearranging the
> virtual vectors (say)
>
> Is this reasonable? It's likely that I've overlooked something or
> somethings. Or maybe this has been done before.. REgardless, any comments
> would be greatly appreciated.
This is exactly how RedBoot works :-) so a look at how it handles
being the ROM monitor (look in redboot/src/main.c) should help.
Indeed, once you have a GDB setup which can set breakpoints, etc,
in the ROM (immutable) code, then there should be nothing else special
required.
--
.--------------------------------------------------------.
| Mind: Embedded Linux and eCos Development |
|--------------------------------------------------------|
| Gary Thomas email: gary dot thomas at mind dot be |
| Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
'--------------------------------------------------------'
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss