Re: GDB support for Flash memory programming

[Peter Barada <peter at the-baradas dot com>]

>>If the flash memory controller has a JTAG interface (most do) then the
>>flash memory can typically be programmed using the same ICE/BDM unit
>>that is used for debugging.
>>  
>>
>Yes, but my experience is this is horribly slow,  due to the polling
>that has to occur of each byte (or programming word for 16bit and 32bit
>wide flashes) as it is programmed.  I think directly programming over
>JTAG/BDM should be avoided, unless there is no alternative.  Even on
>systems where ram is limited, flash could be programmed in chunks, eg:

Another possibility is to have GDB could download/execute a small PIC
function that does the flash programming with its inherent polling
which should speed things up *immensely*.  Also this function can be
tailored to the specifics of the layout (or use global variables for
it). I think the necessary "programming stub" would be small enough to
download, and it would leverage the code that GDB uses to call a
procedure on the target, captures the return, aka:

(gdb) p burn_to_flash(flash_addr, buf_addr, sector_size)

Of course presented to the user to appear as a command as in:

(gdb) burn-flash <src> <sector_size>

where the buf_addr could be on the stack, and capture the result from
the download/call as a command result, that can then generate an error
as in "flash block locked".

This result is extremely extensible to do far more flexible things
that require target manipulation at speeds *far* faster than the
remote protocol can do.

It also allows for manipulating a target that uses a stub that doesn't
even have a JTAG/BDM interface...

-- 
Peter Barada
peter@the-baradas.com