Re: [ECOS] Debugging from ROM

["Gary D. Thomas" <gary dot thomas at mind dot be>]

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