RE: [ECOS] Debugging from ROM

["Rich LeGrand" <rich at charmedlabs dot com>]

Right -- programming the flash on our target is accomplished with a separate
utility.  It programs at 50Kbytes/sec and does not rely on the target
processor -- this is our preferred method.

But I suppose that once the gdb stub is on-flash the stub can program the
flash (requires modifying the stub..)  but I think you are right -- this
could be slow (and tricky to implement!) but possible.  A reasonable
approach would be to relocate the entire stub to RAM before performing the
flash operations.  By interleaving buffers you could approach the datarate
of your communication channel.  (very tricky to implement methinks)

Perhaps other systems with flash have provision for programming the flash
directly.

Best regards,
Rich LeGrand


> -----Original Message-----
> From: Bart Veer [mailto:bartv at ecoscentric dot com]
> Sent: Thursday, March 13, 2003 11:44 AM
> To: rich at charmedlabs dot com
> Cc: ecos-discuss at sources dot redhat dot com
> Subject: Re: [ECOS] Debugging from ROM
>
>
> >>>>> "Rich" == Rich LeGrand <rich at charmedlabs dot com> writes:
>
>     Rich> Thanks for the information!
>     Rich> The reason we are considering this is because there is some
>     Rich> flexibility in our target system. i.e. the flash is mapped
>     Rich> into the processor's address space through some fpga logic
>     Rich> so we can intercept writes to the flash address space,
>     Rich> remember the address, store the result and return the result
>     Rich> when a read. Surprisingly it is only about 20 lines of HDL
>     Rich> code (and simple enough for me to write :) Currently, it can
>     Rich> "alias" 16 words in flash (do you think this is enough?) A
>     Rich> control bit in a register can enable or disable the aliasing
>     Rich> (when disabled the flash contents are "restored")
>
>     Rich> Agreed this is probably not mainstream, but not too many
>     Rich> assumptions are made -- only that the target system has some
>     Rich> programmable logic and that the CE to the flash device is
>     Rich> provided by the programmable logic. (and that the logic has
>     Rich> access to the address and data signals -- but this is
>     Rich> usually the intent with onboard programmable logic) And it
>     Rich> seems like fpgas are becoming more popular for even
>     Rich> lower-end systems.
>
> 16 breakpoints should be fine for normal usage. This approach to
> implementing breakpoints certainly sounds interesting, but there is
> still the problem of getting the code into the flash quickly for the
> normal development cycle. Do you have any plans for that?
>
> 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