[ECOS] Debugging from ROM

Rich LeGrand rich@charmedlabs.com
Thu Mar 13 15:12:00 GMT 2003

Thanks for the information!

The reason we are considering this is because there is some flexibility in
our target system.  i.e. the flash is mapped into the processor's address
space through some fpga logic so we can intercept writes to the flash
address space, remember the address, store the result and return the result
when a read.  Surprisingly it is only about 20 lines of HDL code (and simple
enough for me to write :)  Currently, it can "alias" 16 words in flash (do
you think this is enough?)  A control bit in a register can enable or
disable the aliasing (when disabled the flash contents are "restored")

Agreed this is probably not mainstream, but not too many assumptions are
made -- only that the target system has some programmable logic and that the
CE to the flash device is provided by the programmable logic.  (and that the
logic has access to the address and data signals -- but this is usually the
intent with onboard programmable logic)  And it seems like fpgas are
becoming more popular for even lower-end systems.

Best regards,
Rich LeGrand

> -----Original Message-----
> From: Bart Veer [mailto:bartv@ecoscentric.com]
> Sent: Thursday, March 13, 2003 9:22 AM
> To: rich@charmedlabs.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Debugging from ROM
> >>>>> "Rich" == Rich LeGrand <rich@charmedlabs.com> writes:
>     Rich> I'm not sure if debugging from ROM is something that has
>     Rich> been done very often with eCos and gdb -- perhaps
>     Rich> targets/processors with hardware breakpoints allow this.
>     <snip>
>     Rich> Is this reasonable? It's likely that I've overlooked
>     Rich> something or somethings. Or maybe this has been done
>     Rich> before.. REgardless, any comments would be greatly
>     Rich> appreciated.
> It is theoretically possible, but not exactly mainstream. When doing
> software development you don't want to change the contents of the ROM
> all the time because usually that is much slower than downloading an
> executable into RAM via a ROM monitor - unless you have special
> hardware such as a PROM ICE or a gameboy advance linker. Also,
> although some processors do support facilities like hardware
> breakpoints these tend to be rather limited, e.g. a maximum of four. I
> don't know how well gdb would cope with such limitations - remember
> that some debug operations like single-stepping are also usually
> implemented via breakpoints. However, it should be possible to get
> something working by modifying the existing stubs code.
> If you are thinking of experimenting with this, I would suggest using
> a dedicated communication channel for gdb traffic - at least
> initially. Later on you can think about sharing the serial line
> between gdb and the application.
> Bart
> --
> Bart Veer                       eCos Configuration Architect
> http://www.ecoscentric.com/     The eCos and RedBoot experts

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

More information about the Ecos-discuss mailing list