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 > >
