David,
If I run pyjtag with rproxy running, pyjtag just hangs until I stop
rproxy. Therefore, I don't have any similar experience to yours.
The only error I get is something from pyjtag about the verify failing.
Walt
David Brown wrote:
Yes, I did the "load" command again. However, in light of some other bugs
I've found in my program, I've gone from "convinced" to merely "suspicious".
Do you have rproxy running while you are using pyjtag? I do - it doesn't
seem to make any difference as to whether a pyjtag burn will work or not.
But if it is running and a burn fails, there are a number of error messages
that turn up that may be useful to those that understand the jtag
interface - I get "Could not find device (or device not supported) (4)",
"msp430: Could not read device memory (6)", "msp430: Could not set device
breakpoint (15)", and "msp430: Could not preserve/restore device memory
(12)" at various times.
mvh.
David
Did you reissue the "load" command, and get a good response before running
the code?
I have done this frequently with no noticeable problems.
Walt
Actually, I think things are worse than this - using GDB in this way
gets
something running on the processor, but I am pretty convinced now that
it
is
not correctly burning the program. I find that when I use GDB and get
the
E00 error, the program works mostly, but I get bugs or crashes that were
not
there before. I am now convinced these are caused by incorrect burning
of
the program.
mvh.
David
I too have had problems with loading via pyjtag. It's fast when it
works,
but it's abhorrent at other times. I usually run it from a script
that
checks the return code and retries on failure. Often it works after
only
two or three attempts and sometimes it takes more like a dozen
attempts
before it is successful. Then there are the times that is just will
not
work at all. As you suggest, often changing only a few bytes of code
will
make the difference between pyjtag working on the first attempt, or
not
working at all.
Whenever pyjtag is being particularly uncooperative, I resort to the
GDB/rproxy/FET combination for loading. This is generally really
really
slow, but it pretty much always works. I often get the same error
"Remote
failure reply: E00" when the load completes. However, if I issue the
"load"
command a second time immediately following the error, it completes
successfully and in a very short time.
I would greatly appreciate any pointers/fixes from the rest of the
community, as this business is slowing my development to the point
where
I
am almost ready to buy the IAR tools and work under Windows instead of
my
favored OS which is of course Linux.
Walt
----- Original Message -----
From: "David Brown" <[email protected]>
To: <[email protected]>
Sent: Thursday, December 19, 2002 4:22 AM
Subject: [Mspgcc-users] Problems burning flash with pyjtag, gdb
Hi,
I use pyjtag to burn my programs into the msp430. Mostly it works
fine,
but
sometimes I get a verify error. As far as I can tell, this depends
entirely
on the hex file to burn - if a particular build of the program fails
once,
then it will always fail to burn with pyjtag. It will also have
problems
if
I try to burn it with gdb - downloading from gdb gives the error
"Remote
failure reply: E00". I can download the program with c-spy without
problem.
My workaround at the moment is to make some minor change in the code
and
hope that the new build will burn properly.
I also find burning via gdb to be extremly slow. It is not a big
issue
for
me, since I burn via pyjtag before debugging, but it will probably
be
inconvenient for people who prefer the more graphical interfaces
like
Insight.
mvh.
David
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
