Peter Jansen wrote:
Bryce Himebaugh wrote:
Hello,
I am working with Dr. Brown on the issue of our DCO cal code behaving
differently in gdb than from cold reset. Apparently the "load
code.elf" gdb operation leaves the MSP430 in a state that is
different than cold reset. It now makes sense that this would likely
be the case. However, I did not catch it at first because other
pieces of code have worked fine in gdb without a reset.
I have noticed that the flash lock bit is always cleared (i.e.
unlocked) after doing a load then continue, where as it is set after a
reset. Maybe the load does some other things, it may use some of the
DCO for the flash write clock when doing a load.
Writing directly to flash through the JTAG interface requires fairly
accurate timing. You can't get that from a PC with the parallel port
JTAG interface, so the flash is written by:
Saving the contents of device RAM
Loading a little flash writing program plus some flash data into RAM
Running the programming and checking the result
Repeating the above until all the required flash has been written
Restoring the original contents of RAM
Maybe along the way some things are not properly restored. If that is
the case, it should be the same for mspgcc, and the other 430 tools. We
all use the same TI code to do these things. It could be the other tools
always do a full reset when they have finished loading the flash. I will
look into this when I have time. It seems like you have a usable
workaround for now.
Regards,
Steve
