Ralf Guetlein wrote:
Chris,
it's a x149 with MSP430P140FET, dedicated JTAG pins.
Some additional experiences:
If I do a "jtag.py -Iepvr out.hex", and jtag.py managed to
succeed (i.e. no error msg), the program isn't started.
jtag.py -e file.elf/hex
-e is enough
If I then give a "jtag.py -r" this described error message
occures but the controller starts running... funny!
while connecting it makes a hardware reset (with the reset line)
My guess is:
jtag.py leaves the reset line (or another one crucial for
starting) applied, if it succeeds. If there is an error,
the reset (or other) line is released, which starts the MSP.
(or something alike)
nope.
the cpu runs, but its not correctly reset to start the user app.
at least with my version of the library
In any case, it seems that jtag.py does a bad job when initializing.
For example, the first run of jtag.py after using C-SPY *allways*
works!
when releasing the target it executes a PUC reset with JTAG commands.
that somehow does not work correctly :-(
i'd like fo fix that issue, but time and hardware do debug was missing
until now ;-)
but appart from that reset problem on release it works realy well for
me. i have no connection problems at all.
differences between cspy and our tools can come from different timing.
the timing for the communication on the JTAG interface is generated by
the software and there are different backedns. it may be that on some
board designs with high capacitance or low resitant circuits on the JTAG
pins may casue problems (altough such problems are more likely with the
shared data/JTAG pins than with the dedicated JTAG port)
chris
