Re: GDB support for Flash memory programming

[Russell Shaw <rjshaw@netspace.net.au>]

Jim Blandy wrote:
> Russell Shaw <rjshaw@netspace.net.au> writes:
> 
>>Jim Blandy wrote:
>>
>>>One of the problems GDB has in the embedded development world is its
>>>lack of support for loading programs into flash memory.  After some
>>>conversation amongst ourselves to weed out patently stupid stuff (none
>>>of the text below is mine... hey), we at CodeSourcery put together the
>>>following proposal for general comments and criticism.  We'd like to
>>>reach consensus on what the user interface should be
>>>before we worry about implementation details --- possible remote
>>>protocol changes, and so on --- so let's leave those topics aside for
>>>the time being.
>>>What do folks think?
>>>---
>>>Background
>>>Flash memory is a popular form of non-volatile memory...
>>
>>I've done all this stuff for the AVR by adding my own comms handling
>>and memory-space/type handling code to gdb for communicating with a
>>specific jtag ice.
>>
>>IMO, the generic stub thing should only be used for targets that
>>receive the commands without any intermediate ICE/debugger hardware
>>(these targets interpret gdb commands with their own software).
>>
>>IMO, every supported hardware device (jtag debuggers etc) should
>>have their own directory in gdb. It is much easier to take advantage
>>of specific debugger features, instead of relying on lowest common
>>denominator features of the generic gdb stub shim thing. Shims add
>>unnecessary delay and cludginess because of the extra layer of comms
>>overhead.
> 
> Well, how the solution should be structured in the code is going to be
> an interesting point of discussion.  But as I say to Steven, we'd like
> to get feedback on the user interface first.  Would the interface as
> proposed be useful in the work you're doing now?

I've been stuck on desktop programming for months, so i haven't done
embedded stuff for ages. Anything that improves the situation for
embedded targets would be good.

A characteristic of micro-controller embedded targets is multiple memory
spaces, such as small ones just for programming device config. fuses etc.
As well as being read/write or read-only, the spaces can vary in width.
Some may be 8-bit, while others are 16-bit or more. Whether this needs
improving, i can't tell until i get into gdb hacking again.