ave been a little frustrating
to use (pyjtag often failed to load my code, and rproxy/gdb was really
slow when loading code) but the problem has been adequately addressed by
recent improvements to pyjtag.
I say, go for it. Hats off to the developers, and many many thanks!
Walt Spicker
J.C.
in a
particular state (say 0). Tie the input hi for normal operation, and if
your target starts misbehaving again, force the input low and see if that
helps.
Walt Spicker
- Original Message -
From: "David Brown"
To:
Sent: Monday, January 06, 2003 12:21 PM
Subject: [Mspgcc-users] Pro
ag.so.
Walt Spicker
bytes. Extend to 4 bytes gives
0xf800
In case you're play with i368, the last numbers are:
(0xf - 0x1) >>2 == 0xe000 >> 2 == 0x3800
To prove this, try 0x1000 and 0xf000 on i368 and check.
Hope this helps.
~d
On Tuesday 31 December 2002 05:17, Wa
ed example.
perhaps even a const long array in the code section
that just happens to cross the 32k byte boundary
would also experience this size failure.
On Mon, 30 Dec 2002 at 17:14 -0500, walt spicker
From: walt spicker
To: David Dyck
Date: Mon, 30 Dec 2002 17:14:09 -0500
Subject: Re: [M
Christian,
I had the same problem. As I recall, I saw an explanation somewhere, I
think on this list. You need to go to CVS, get the "jtag" module and
invoke make in jtag/hardware_access/HILpppdev to produce the library. I
think that's all I did. If it does not work, or you have trouble, s
0, it is 32bits. Try long long
Garst
walt spicker wrote:
Hello,
I'm having trouble with the following pointer math. I get a different
result from the MSP430 GCC when I execute the same code compiled with
GCC for intel 386. Here is an example:
unsigned long *p1=(void*)0x1000, *p2
("%8.8lx %8.8lx\n", p2p1, p3p1);
}
Here is the result
00001800 00003800
Help Please,
Walt Spicker
Salient Systems Inc.
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 li
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
- Original Message -
From: "David Brown"
To:
Sent: Friday, December 20, 2002 9:44 AM
Subject: Re: [Mspgcc-users] Problems burning flash with
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
proxy under Linux, but it does work under Cygwin.
Walt Spicker
Salient Systems, Inc
4330 Tuller Road
Dublin, Ohio 43017
Tel 614 792-5800
Fax 614 792 5888
- Original Message -
From: "David Brown"
To:
Sent: Wednesday, December 11, 2002 5:42 AM
Subject: [Mspgcc-users] Problems l
have any work around for this problem.
Regards,
Walt Spicker
Steve Underwood wrote:
Hi all,
I have put the first test version of rproxy on the mspgcc web site.
This is a new program which sits between msp430-gdb and the TI Flash
Emulation Tool (FET - also known as the parallel port JTAG tool)
13 matches
Mail list logo
