It would have been easy if the problem had been gdbproxy, but no such luck.
Now that mspdebug is running, I'm seeing exactly the same scenario here. The
messages are a tad different, but I think they are saying the same thing.
Everything works fine until mspdebug reports...
fet: FET returned error code 18 (Could not determine device state)
fet: polling failed
Once again, eveything appears hung outboard of mspdebug until the target msp
is repowered. If I simply try and restart mspdebug without doing this, it
will report;
TI3410 device is in boot config, setting active
ti3410: TI_OPEN_PORT failed: A device attached to the system is not
functioning
ti3410: failed to set up port
Any ideas?
Andrew
No reason at all except maybe laziness. I did have a play with mspdebug a
few years back, and from memory had some issues with the target processor I
was using. gdbproxy worked, so I've stayed with that ever since. There is
always enough work in the code itself, so if the environment works I just
tend to leave it alone. I wasn't aware there was any formal plans to
deprecate gdbproxy, but was aware of a lot of the development/support
discusssions around this.
I'm in the process of reinstalling mspdebug, so we'll see if that makes any
difference. I'll let you know!
Thanks - 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
