Hermann Kraus wrote:
On Fri, 23 Apr 2004 07:15:02 -0400, <kbaud...@tampabay.rr.com> wrote:
Is it possible to connect the debugger to a running application on a
MSP430,
such that the application is not reset?
the JTAG hardware requires a fuse check and synchronization.
to get the CPU in a known state, the first synchronization requires a
POR reset.
you can use the method described below in some many cases, but it's not
the best practise :-)
I had the same problem. I didn't find a clean way to do this. But the
following works:
You need a second board with an identical MSP. It is sufficient to
connect JTAG and power pins only. You don't need the other
hardware from you application board. I'll call this "board 2" and your
real application board will be "board 1".
1. Connect the JTAG interface to board 2.
2. Start msp430-gdbproxy
3. Start msp430-gdb and type the following commands:
(gdb) tar r :2000
(gdb) cont
4. Now remove the JTAG connector from board 2 and connect it to board 1.
5. Now you should be able to debug your application without resetting it.
It would be better to be able to set the mcu-type with an gdbproxy
commandline parameter and make it work this way.
But this seems to be unimplemented (yet?).
maybe that could be done, but i see some drawbacks:
- the server runs for many sessions, such a switch would make sense
for one session only (changing boards/CPUs...)
- there is a large potential for confusion and missuse which could
lead to specifying the switch when not needed and/or forcing to use the
wrong CPU.
- it does not solve the "do not reset on connection problem". as
explained above, the reset is part of a clean sync sequence. once the
cpu is synchronized and its state saved, identification can be done as
everything else is. so what you realy want is a sloppy init switch ;-)
well, mabe something with the "monitor" commands could be done,
supporting one or both switches mentioned above but don't count on it.
somebody needs to implement and test it and the number of programmers
that could do that is 2, both also having different work to do...
chris