> Carles Perello wrote:
>
> >hmm seems that issuing the command
> >
> >monitor erase all
> >load
> >
> >solves the problem...probably insight frontend does not issue the
> >commands correctly for this target
> >
> gdb hasn't a clue about devices with flash. It has been used for a lot
> of embedded work for years, but still hasn't caught up with the special
> qualities MCUs have.
>
> gdb never issues a "monitor erase all" for itself. You have to do it.
> I'd like to automate it, but it isn't clear how to do that without
> annoying side-effects.
>
I use gdb with a bdm interface for the 68332, which requires a bit of setup
before downloading the program (no erase - I put the program in static ram -
but it needs chip selects set up). To automate the process, I have a macro
in the gdb.ini file in the project directory which does this setup. When
using gdb for the msp430 (I still haven't tried it yet - I haven't got my
current program finished and ready to debug), I expect to have macros along
the lines of:
define init
set remotetimoeut 999999
set remoteaddresssize 64
target remote localhost:4411
end
define download
init
monitor erase all
load
end
Thus (assuming gdb.ini is automatically loaded, or the macros are in
.gdbinit for Linux, or you start with gdb -x gdb.ini) you can use "download"
instead of "load". I think that this sort of arrangement is a lot better
than trying to do something automatically by changing gdb/insight - gdb
gives you the power for such automation, so why not use it? There are times
when you specifically don't want to change the flash, but still want to do
debugging, or perhaps you only want to erase some of the flash. Or perhaps
the program is targeted to run from ram.
