is there some reason you are using msp430-gdbproxy rather than mspdebug?
msp430-gdbproxy has been deprecated for many years now.
current devlopment is occuring on mspdebug.
it is a superset of msp430-gdbproxy.
On Sat, Aug 24, 2013 at 6:16 PM, Andrew McLaren <and...@aratika.co.nz>wrote:
> I've been struggling with an (almost) repeatable issue with gdpproxy losing
> connection with the target msp.
>
> After operating correctly for a period, gdbproxy will suddenly report
> "error: msp430: Could not determine device state (18)" in response to an
> MSP430_State() request by gdbproxy.
> then following this a stream of
> "error: msp430: No error (0)" in response to a sequence of
> MSP430_Memory(READ) requests.
>
> At this point I've only been able to get this working again by repowering
> the FET and the target msp (actually the target msp looks like its enough,
> but its typically powered via the FET).
>
> >From this I'm guessing that something in the logic being debugged is
> corrupting the target msp's JTAG interface in some way, which effectively
> disrupts communication with the FET. Repowering the target msp resets all
> the interfaces to a known state, which gets things back in line. However,
> even if this is the case, I'm not having much luck isolating where this is
> happening, and hoping someone can give me some ideas or pointers which may
> help in isolating this.
>
> When I said 'almost' above, often this seems to trigger in the same
> sequence
> in the logic, but not always, so its not totally predictable. I've been
> trying to 'binary chop' the logic from where it is known good to where it
> is
> often bad, but the lack of predicatability is running me in circles. I've
> also forced the code to link in a different order (theory being that if it
> was a relative addressing rather than absolute addressing issue, the
> problem
> would move), but its remained much the same (but of course the lack of
> predicatability means I can't be certain!) Where it is occuring it should
> be
> running logic that has all previously been exercised a number of times.
>
> - Does my diagnosis sound right, or at least reasonable?
> - From what I can glean, the target msp (a 439) has a dedicated JTAG
> interface, and can't see that any of this is configurable, even
> inadvertently. Am I missing something here, or is there some other way the
> JTAG interface can be impacted?
> - Any other ideas for what could cause this?
> - Any ideas or techniques for isolating this sort of problem.
>
> The setup is Eclipse talking to the target MSP (a 439) via msp430-gdbproxy
> (version 0.7.1), and a TI USB FET.
>
> Thanks for any thoughts.
>
> Andrew
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
